feat: new relic integration

[yotor1221]

feat: Add New Relic integration OnIssue ,runNRQL and reportmetric

Description

Implements #2552.

This PR implements the native New Relic integration, which allows users to trigger workflows based on New Relic issues (OnIssue), execute deep telemetry queries (RunNRQLQuery), and report custom business metrics (ReportMetric) back to New Relic.

Authorization is via API keys:

• RunNRQLQuery: Requires a User API Key (starts with NRAK-).
• ReportMetric: Recommended to use with a License Key (Ingest - License).

a video demo

https://www.loom.com/share/b5554aa5781e49e98b55eb0bab80a9da

Backend Implementation

The backend implementation code is in pkg/integrations/newrelic/.

• Structure: Follows existing patterns using newrelic.go for registration and separate files for triggers/actions (on_issue.go, run_nrql_query.go, report_metric.go).
• Key Features:
  • GPG Signing: All commits are GPG signed.
  • Configuration Persistence: Fixed UI state issues by enforcing strict string typing in OnIssue and RunNRQLQuery structs.
  • Smart Templates: Added logic to intercept unresolved template tags (e.g., {{account_id}}) to prevent invalid API calls.
• Example Output: JSON examples for component outputs are included in the code comments and documentation.

Frontend Implementation

This integration uses the Server-Driven UI (SDUI) pattern. The frontend forms are automatically generated from the Go configuration structs defined in the backend.

• Persistence Fix: ensuring field types (e.g., FieldTypeIntegrationResource) map correctly to string inputs in the UI has resolved previous selection issues.

Docs

Documentation has been generated in docs/components/New Relic.mdx by running make gen.components.docs.

It includes:

• Setup instructions (API Key generation).
• Usage guides for OnIssue, Run NRQL Query, and Report Metric.
• Example configuration and data payloads.

Tests

Unit tests are located in pkg/integrations/newrelic/.

• run_nrql_query_test.go: Covers query execution, template variable validation, and context fallback logic.
• on_issue_test.go: Covers webhook validation, payload parsing, and event filtering.
• repro_test.go: Specifically tests UI configuration persistence and type handling.
• report_metric_test.go: Covers metric payload construction.

Tests are deterministic and pass locally.

[AleksandarCole]

@yotor1221 thanks for the video instructions - very clear and useful!

The main issue I see right now is that we need 2 types of API keys. There is no sense in user switching this in configuration.

We should have an integration form that asks you to create both keys - explaining which is used for which. User can configure only one or the other (which is fine) - but then the component needs to know if configuration has what it needs.

For example, if I have user API key configured only - the runNRQL and onIssue need to show configuration as green while reportMetric shows it as orange (not configured)

---

I will assign engineering to this one for a quick review of the approach, before I proceed with more in-depth functional/UX testing.

[yotor1221]

@yotor1221 thanks for the video instructions - very clear and useful!

The main issue I see right now is that we need 2 types of API keys. There is no sense in user switching this in configuration.

We should have an integration form that asks you to create both keys - explaining which is used for which. User can configure only one or the other (which is fine) - but then the component needs to know if configuration has what it needs.

For example, if I have user API key configured only - the runNRQL and onIssue need to show configuration as green while reportMetric shows it as orange (not configured)

I will assign engineering to this one for a quick review of the approach, before I proceed with more in-depth functional/UX testing.

Hi @AleksandarCole
Thanks for the feedback. That makes total sense splitting the keys in the integration form will definitely provide a better UX. I'll update the configuration to support both User API Keys (for NRQL/Triggers) and License Keys (for Metrics) simultaneously.

I will also implement the validation logic so the components visually reflect their 'ready' status based on which keys are provided. I'll ping you once the updated flow is ready for review.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[yotor1221]

Hi @AleksandarCole ,

I have updated the integration to address the API key configuration and improve the setup UX:

Dual-Key Support: The integration now accepts both userApiKey and licenseKey simultaneously. Users no longer need to switch between them manually.

Component-Specific Logic: Components now independently verify their required keys. If only a User API Key is provided, RunNRQLQuery and OnIssue will initialize successfully, while ReportMetric will identify the missing License Key during setup.

Simplified Configuration: I have removed the manual Account ID field from the NRQL component. Since the integration is already managing this via the dynamic picker, the manual input was redundant. This prevents user error and streamlines the configuration process.

Clear Feedback: While the core UI doesn't currently support an 'Orange' status for partial configurations, I have implemented explicit validation in Setup(). If a required key is missing, the component displays a clear error: 'User API Key/License Key is required for this component. Please configure it in the Integration settings.' This ensures the user knows exactly which credential is missing without affecting other working components.