Add jsmops (JSM Ops) notifier as Opsgenie migration target#5373
Add jsmops (JSM Ops) notifier as Opsgenie migration target#5373jothimanikrish wants to merge 6 commits into
Conversation
Implement a new notify/jsmops/ package targeting the Jira Service Management Operations REST API. This is the supported migration path for the deprecated Opsgenie notifier (EOL April 2027). Key differences from opsgenie: - Auth delegated to http_config (no api_key fields) - Required cloud_id per receiver config - URLs built via APIURL.JoinPath(cloudID, "v1", "alerts", ...) - Update requests use PATCH (per JSM Ops OpenAPI spec) Includes: - Full notifier implementation with create/close/update lifecycle - Config schema, global defaults, per-receiver defaulting - Integration registration in config/receiver - Default templates (jsmops.default.message/description/source) - Comprehensive test suite mirroring opsgenie patterns - Documentation in docs/configuration.md and CHANGELOG.md Signed-off-by: jothimanikrish <jothimanikrish@hotmail.com>
jothimanikrish
force-pushed
the
feature/jsmops-notifier-integration
branch
from
35db0b9 to
4c8cf0f
Compare
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds a JSM Ops notifier with configuration parsing, responder validation, API URL inheritance, alert create/close/update requests, default templates, documentation, changelog coverage, and tests. ChangesJSM Ops receiver integration
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant Alertmanager
participant ReceiverConfig
participant JSMOpsNotifier
participant JSMOpsAPI
Alertmanager->>ReceiverConfig: load jsmops_configs
ReceiverConfig->>JSMOpsNotifier: build notifier
Alertmanager->>JSMOpsNotifier: Notify alerts
JSMOpsNotifier->>JSMOpsAPI: create, close, or update alert
JSMOpsAPI-->>JSMOpsNotifier: HTTP response
JSMOpsNotifier-->>Alertmanager: retry decision and error
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
notify/jsmops/config_test.go (1)
29-40: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAdd assertion that responder
Typeis normalized after parsing.This case exercises mixed-case types ("scheDule", "teams", "USER") but only checks
require.NoError. It doesn't assert that the parsed config actually stores the lowercased value, which is why the range-copy bug innotify/jsmops/config.go(see review comment there) went unnoticed.require.NoError(t, err) require.Equal(t, "schedule", cfg.Responders[0].Type) require.Equal(t, "teams", cfg.Responders[1].Type) require.Equal(t, "user", cfg.Responders[2].Type)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@notify/jsmops/config_test.go` around lines 29 - 40, The “valid configuration” test only checks that parsing succeeds, so it misses whether responder types are actually normalized. In config_test.go, update the test that exercises mixed-case responder types to assert the parsed cfg.Responders entries have lowercased Type values after parsing, using the cfg.Responders slice and its Type field to verify schedule, teams, and user normalization.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@notify/jsmops/config.go`:
- Around line 80-95: The responder type normalization in the jsmOps config
validation is only applied to the loop copy, so mixed-case types are not
persisted back into the config. Update the responder validation logic in the
c.Responders loop to iterate by index and assign the lowercased value back into
c.Responders[i].Type after the ContainsTemplating check, while preserving the
existing validation using jsmopsTypeMatcher and jsmopsValidTypesRe.
In `@notify/jsmops/jsmops.go`:
- Around line 182-210: The responder filtering in jsmOps message creation is too
weak because it only skips fully empty jsmOpsCreateMessageResponder values,
allowing identifier-less responders through when only Type is populated. Update
the responder-building loop in the JSM Ops message creation logic to reject
responders that do not have at least one valid identifier field (ID, Name, or
Username) after templating, while still preserving the special teams-to-team
expansion path. Keep the check close to the existing responder construction so
malformed responders are filtered before appending to responders.
---
Nitpick comments:
In `@notify/jsmops/config_test.go`:
- Around line 29-40: The “valid configuration” test only checks that parsing
succeeds, so it misses whether responder types are actually normalized. In
config_test.go, update the test that exercises mixed-case responder types to
assert the parsed cfg.Responders entries have lowercased Type values after
parsing, using the cfg.Responders slice and its Type field to verify schedule,
teams, and user normalization.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 4db83b0a-d437-41d5-b861-7e9675fbb245
📒 Files selected for processing (11)
CHANGELOG.mdconfig/config.goconfig/config_test.goconfig/receiver/receiver.goconfig/testdata/conf.jsmops-default-apiurl.ymldocs/configuration.mdnotify/jsmops/config.gonotify/jsmops/config_test.gonotify/jsmops/jsmops.gonotify/jsmops/jsmops_test.gotemplate/default.tmpl
- Iterate responders by index so strings.ToLower persists the normalized type back into the config struct. Previously the range-copy meant mixed-case types like "Teams" passed validation but failed the == "teams" check at notification time. - Add a post-templating guard that skips responders whose identifier fields (ID, Name, Username) all evaluated to empty strings, preventing type-only responders from reaching the API. Signed-off-by: jothimanikrish <jothimanikrish@hotmail.com>
|
Context: Atlassian is officially retiring Opsgenie and folding its on-call and alerting features directly into Jira Service Management (JSM) Premium and Enterprise tiers. Opsgenie reaches its full end-of-support on April 5, 2027 However I wonder if JSM Ops only provides the opsgenie compatible API or if there other options, maybe even usable with the webhook notifier . Eg this https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v2/api-group-alerts/#api-api-cloudid-v1-alerts-post ? |
The JSM Ops REST API supports basic auth and OAuth 2.0 authorization code grants (3LO). Alertmanager's oauth2 http_config implements the client credentials grant, which this API does not support, so remove the claim that oauth2 works and document basic_auth (Atlassian account email + API token) as the only working method, including the one-year maximum API token lifetime. Signed-off-by: jothimanikrish <jothimanikrish@hotmail.com>
The update_alerts message PATCH request was appended without WithContext(ctx), unlike the create, close, and description requests, so it would not be cancelled with the notification context. Signed-off-by: jothimanikrish <jothimanikrish@hotmail.com>
|
Thanks for raising this. JSM Ops actually exposes two API surfaces: An Opsgenie-compatible integration API (https://api.atlassian.com/jsm/ops/integration/) — this is what JSM's built-in "Prometheus" integration uses, and the existing opsgenie receiver already works against it by just overriding api_url (confirmed in #4244, and why #3949 was closed). The documented customer REST API (the one you linked) — officially versioned, authenticated with basic auth (account email + API token). This PR targets this one. The webhook receiver could only cover alert creation: closing requires a POST to a different path (/alerts/{id}/close) and updates use PATCH, while the webhook posts firing and resolved to a single URL — so the create/close/update lifecycle can't be expressed with it. For additional context: my own production setup currently runs the existing opsgenie receiver against https://api.atlassian.com/jsm/ops/integration/ (with the API key from JSM's Prometheus integration), and it works fine — so the URL-swap path from #4244 is confirmed working. If required, I'm happy to rework this into a docs-only change documenting the api_url override as the supported migration path. |
2 participants
Pull Request Checklist
Please check all the applicable boxes.
Please list all open issue(s) discussed with maintainers related to this change
Is this a new Receiver integration?
Is this a bugfix?
Is this a new feature?
Does this change affect performance?
I have provided benchmarks comparison that shows performance is improved or is not degraded
I have added new benchmarks if required or requested by maintainers
Is this a breaking change?
My changes do not break the existing cluster messages
My changes do not break the existing api
I have added/updated the required documentation
I have signed-off my commits
I will follow best practices for contributing to this project
Which user-facing changes does this PR introduce?