feat(newrelic): APM application id can be looked up by name

[3bbbeau]

Summary

This is intended to be a quality of life feature to allow ArgoCD ApplicationSet resources to minimize boilerplate when dealing with NewRelic APM resources across multiple environments.

Currently

• An application programmatically uses the NR SDK to report to NewRelic
• NewRelic APM Application ID has to then be retrieved following the first run of an application from the NR Dashboard and added to an ArgoCD Application via the annotation, across multiple environments.

---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    notifications.argoproj.io/subscribe.<trigger-name>.newrelic: 123456789

Desired

Using ArgoCD ApplicationSet resources, the annotation can be either provided via the application id as the above example, or instead by name, e.g. MyApp-{{ .values.env }}:

---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    notifications.argoproj.io/subscribe.<trigger-name>.newrelic: MyApp-Dev

---

Logic

If dest.Recipient can be parsed to an int, then the application id was directly provided and logic remains as before.

If dest.Recipient cannot be parsed to an integer, then it was passed by name (since all NewRelic APM IDs are defined as integers within the schema) and we call /v2/applications.json to query using filter[name]

If /v2/applications.json returns multiple application IDs then an error is returned, as we can't determine which application id to use to place the deployment marker.

[crenshaw-dev]

I'd use the url library to construct this, to avoid appName potentially injecting arbitrary stuff

[crenshaw-dev]

+1, use url package to construct URLs

[crenshaw-dev]

Instead of reusing Recipient, could you use a new RecipientName field? Clarifies the UX and avoids any weirdness around, for example, a name that happens to also be a number.

[3bbbeau]

Thank you for taking a look at this. I first interpreted your comment as changing the Destination struct but I'm not actually sure where you mean without making this change of wider significance.

I had a look at the other services to see how they had handled service-specific changes in recipient fields:

notifications-engine/pkg/services/rocketchat.go

Lines 75 to 79 in f189f7e

	// It's a channel
	if strings.HasPrefix(dest.Recipient, "#") || strings.HasPrefix(dest.Recipient, "@") {
	message.Channel = dest.Recipient
	} else {
	message.RoomID = dest.Recipient

notifications-engine/pkg/services/telegram.go

Lines 28 to 45 in f189f7e

	if strings.HasPrefix(dest.Recipient, "-") {
	chatID, err := strconv.ParseInt(dest.Recipient, 10, 64)
	if err != nil {
	return err
	}
	// Init message with ParseMode is 'Markdown'
	msg := tgbotapi.NewMessage(chatID, notification.Message)
	msg.ParseMode = "Markdown"
	_, err = bot.Send(msg)
	if err != nil {
	return err
	}
	} else {
	// Init message with ParseMode is 'Markdown'
	msg := tgbotapi.NewMessageToChannel("@"+dest.Recipient, notification.Message)
	msg.ParseMode = "Markdown"

---

Could we do something similar with name: 12345678 and id: 12345678 and default to the latter given no prefix for backwards compatibility? That would leave the Destination struct alone and address the issue of New Relic APM names that happen to be numbers.