Add jsmops (JSM Ops) notifier as Opsgenie migration target

[jothimanikrish]

Pull Request Checklist

Please check all the applicable boxes.

• Please list all open issue(s) discussed with maintainers related to this change

  • Fixes #

• Is this a new Receiver integration?

  • I have already tried to use the Webhook Receiver Integration and 3rd party integrations before adding this new Receiver Integration

• Is this a bugfix?

  • I have added tests that can reproduce the bug which pass with this bugfix applied

• Is this a new feature?

  • I have added tests that test the new feature's functionality

• 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?

[FEATURE] Add `jsmops` (Jira Service Management Operations) receiver as the migration target for the deprecated `opsgenie` receiver. Authentication is delegated to `http_config` (Basic Auth or OAuth 2.0); a per-receiver `cloud_id` is required.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 673fe30a-787d-496c-b81f-0781b74af0a7

📥 Commits

Reviewing files that changed from the base of the PR and between dd8a5ac and 925d725.

📒 Files selected for processing (1)

• docs/configuration.md

✅ Files skipped from review due to trivial changes (1)

• docs/configuration.md

---

📝 Walkthrough

Walkthrough

This PR adds a new jsmops notifier, its config schema and validation, config wiring for global and receiver settings, default templates, documentation, and tests.

Changes

JSM Ops receiver integration

Layer / File(s)	Summary
JSMOpsConfig schema and validation notify/jsmops/config.go, notify/jsmops/config_test.go	Defines JSMOpsConfig/JSMOpsConfigResponder, default values, responder-type validation, and YAML unmarshalling rules that require cloud_id and validate responders, with tests.
JSM Ops notifier implementation notify/jsmops/jsmops.go, notify/jsmops/jsmops_test.go	Implements notifier construction, retry handling, request generation for resolved and firing alerts, responder expansion, update requests, and tests for retry behavior, secrets, payloads, and update flow.
Global/receiver config wiring config/config.go, config/config_test.go, config/receiver/receiver.go, config/testdata/conf.jsmops-default-apiurl.yml	Adds global and receiver config fields, default API URL handling, receiver normalization, and integration wiring, with tests and fixture coverage.
Default templates, docs, and changelog template/default.tmpl, docs/configuration.md, CHANGELOG.md	Adds default JSM Ops templates, documents the new configuration options, and records the change in the changelog.

Estimated code review effort: 3 (Moderate) | ~30 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: introducing jsmops as the Opsgenie migration target.
Description check	✅ Passed	The checklist and release note are mostly complete, but the open issue reference is still a placeholder instead of an actual linked issue.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

notify/jsmops/config_test.go (1)

29-40: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Add assertion that responder Type is 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 in notify/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

📥 Commits

Reviewing files that changed from the base of the PR and between bb956c9 and 4c8cf0f.

📒 Files selected for processing (11)

• CHANGELOG.md
• config/config.go
• config/config_test.go
• config/receiver/receiver.go
• config/testdata/conf.jsmops-default-apiurl.yml
• docs/configuration.md
• notify/jsmops/config.go
• notify/jsmops/config_test.go
• notify/jsmops/jsmops.go
• notify/jsmops/jsmops_test.go
• template/default.tmpl

[TheMeier]

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
https://www.atlassian.com/software/opsgenie/migrationhttps://www.atlassian.com/software/opsgenie/migration

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 ?