GHA-300 Automated release workflow should use new plugin deployment workflow

[nils-werner-sonarsource]

Summary

When `sqc-integration: true` and `sqc-plugins-deployer-integration: true`, the automated release opens PRs in both repositories simultaneously during the transition period:

1. `sonarcloud-core` — existing `build.gradle` update (unchanged)
2. `sonar-plugins-deployer` — new `plugins.yaml` anchor update (this PR)

The `sqc-plugins-deployer-integration` input defaults to `false` so existing callers are unaffected until they opt in.

Changes

File	Change
`update-plugins-deployer/action.yml`	New composite action — vault → validate SC- ticket → sparse checkout `plugins.yaml` → sed anchor update → create PR
`update-plugins-deployer/update_plugins_yaml.sh`	Shell script: computes anchor key from `plugin-name` (strips `-enterprise`, maps `csharp`/`vbnet` → `dotnet`), updates version anchor in `versions:` block, fails hard if anchor not found
`update-plugins-deployer/test_plugins.yaml`	Fixture `plugins.yaml` used by action tests
`update-plugins-deployer/test_update_plugins_yaml.sh`	7 shell unit tests covering all key-mapping cases
`update-plugins-deployer/README.md`	Action documentation
`.github/workflows/test-update-plugins-deployer.yml`	CI: unit tests + action tests (ticket validation, fixture-based anchor update for java/security/go-enterprise/dotnet-enterprise)
`.github/workflows/automated-release.yml`	Add `update-plugins-deployer` step alongside `update-sqc`; new `sqc-plugins-deployer-integration` input (default `false`); new `plugins-deployer-pull-request-url` output; updated summaries
`README.md`	Add `update-plugins-deployer` to actions table

Artifact → anchor key mapping

`plugin-artifacts-sqc` value → anchor in `versions:` block:

• `security` → `sonar-security`
• `go-enterprise` → `sonar-go`
• `iac-enterprise` → `sonar-iac`
• `text-enterprise` → `sonar-text`
• `python-enterprise` → `sonar-python`
• `csharp-enterprise`, `vbnet-enterprise` → `sonar-dotnet` (shared anchor)
• `java`, `java-symbolic-execution`, `php`, etc. → `sonar-{plugin-name}`

Test strategy

Automated tests (CI)

• Unit tests (`test_update_plugins_yaml.sh`): 7 shell tests covering all anchor key-mapping cases and the hard-fail path for unknown plugins. Run without any external dependencies.
• Action tests (workflow): ticket format validation (SONAR-/INVALID- rejected, SC- required) + fixture-based anchor update tests for java, security (with frontends sharing one anchor), go-enterprise, and dotnet-enterprise. Use a local `test_plugins.yaml` fixture — no vault, no network access to `sonar-plugins-deployer`.

End-to-end test (manual, completed)

A full draft release was triggered from SonarSource/sonar-php using a test branch (`nw/test-plugins-deployer-release`) pointing at this PR's branch with `sqc-plugins-deployer-integration: true`, `is-draft-release: true`, and `use-jira-sandbox: true`.

Result: sonar-plugins-deployer#46 was created as a draft with the correct diff — only the `sonar-php: &version-sonar-php` anchor line updated, all alias references untouched. The PR was closed after verification.

Prerequisites (separate PRs)

• re-terraform-aws-vault #9142 — adds `sonar-plugins-deployer` to all `release-automation` secrets ✅ merged
• sonar-plugins-deployer #41 — adds YAML anchors to `versions:` block for all plugins

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

GHA-300

[sonar-review-alpha]

Summary

What: Adds a new update-plugins-deployer composite action that updates plugin version anchors in sonar-plugins-deployer/plugins.yaml, and integrates it into the automated release workflow alongside the existing SQC integration.

Why: During the transition to sonar-plugins-deployer, release automation needs to update plugin versions in two places simultaneously. The action handles YAML anchor updates (not direct version fields), which allows all alias references in the plugins: block to inherit the new version automatically.

Scope: The new feature is opt-in — the sqc-plugins-deployer-integration input defaults to false, so existing callers are unaffected until they explicitly enable it.

What reviewers should know

Start here:

1. Anchor key logic (update_plugins_yaml.sh:4-19): The mapping from plugin-name → anchor key is the critical piece. Review the transformation rules (strip -enterprise, map csharp/vbnet → dotnet) and ensure it matches the anchor keys defined in sonar-plugins-deployer.
2. Integration point (.github/workflows/automated-release.yml:790-796): The new step mirrors the existing update-sqc pattern — same inputs, same conditional guard (sqc-integration && sqc-plugins-deployer-integration).

Key design decisions to verify:

• The shell script uses sed for inline YAML anchor updates rather than a YAML parser — this is intentional to avoid external dependencies and keep the anchor format exact (format must match sonar-{key}: &version-sonar-{key} VERSION).
• The test fixture approach (static test_plugins.yaml) avoids vault/network dependencies during testing.
• Ticket validation happens in the action's bash step (not the script), enforcing SC- prefix only when creating PRs.

Watch for:

• The anchor pattern matching in update_plugins_yaml.sh is strict — if a plugin is missing from the versions: block in sonar-plugins-deployer, the script fails hard with a clear error. This is intentional (fail-fast behavior), but reviewers should verify the error message is helpful.
• The test coverage includes both happy paths (successful anchor updates) and failure modes (unknown plugin, invalid ticket prefixes).
• The mapping for dotnet-enterprise is special — verify that sonar-plugins-deployer's plugins.yaml has a single sonar-dotnet anchor shared by both csharp-enterprise and vbnet-enterprise plugins.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[yasen-pavlov-sonarsource]

LGTM! Left one comment regarding the plugin-artifacts input.

[sonar-review-alpha]

The incremental diff is a clean, focused removal of the plugin-artifacts input — the README, action.yml, test workflow, and script comment are all updated consistently. One stale comment slipped through, and the ticket-validation test coverage concern from the previous review remains unaddressed.

🗣️ Give feedback

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud