[nils-werner-sonarsource]

Summary

• Extends update-analyzer action with an explicit target input (sqs/sqc/sqaa), falling back to ticket-key prefix routing for backward compatibility
• Adds TOML sed pattern for sqaa target (updates gradle/libs.versions.toml in sonar-analysis-as-a-service)
• Adds sqaa-integration (default: false) and plugin-artifacts-sqaa inputs to automated-release.yml; sqaa reuses the SC ticket key and requires sqc-integration: true
• Wires sqaa-pull-request-url through job outputs, workflow outputs, and the release summary

Prerequisites

A separate re-terraform PR must be merged to grant release-automation secrets access to sonar-analysis-as-a-service before enabling sqaa-integration: true in any analyzer workflow.

Test plan

• Verify update-analyzer still routes correctly for existing SONAR-* and SC-* ticket keys (no target input)
• Verify new target: sqaa produces a PR in sonar-analysis-as-a-service updating gradle/libs.versions.toml
• Verify sqaa-integration: false (default) skips the sqaa step entirely
• Verify sqaa-pull-request-url appears in the workflow summary when enabled

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

GHA-338

[karim-ouerghemmi-sonarsource]

LGTM in general. Thanks for handling this!
Please check the one Gitar comment.

[nils-werner-sonarsource]

gitar auto-apply:on

[nils-werner-sonarsource]

Using #157 instead

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Integrates SQAA into release automation by adding target routing, TOML update logic, and PR tracking. Resolved issues regarding TOML over-matching and silent failures when SQAA is enabled without SQC.

✅ 2 resolved

✅ Edge Case: TOML sed pattern over-matches plugin keys with shared prefix

📄 update-analyzer/action.yml:122 📄 update-analyzer/action.yml:128-132
When plugin-artifacts is not supplied, the plugin pattern defaults to ${PLUGIN_NAME}.* (line 122). For the new TOML target this is interpolated into:

sed -i "s/^\(sonar-$plugin\s*=\s*"\)[0-9.]*/\1$RELEASE_VERSION/" "$BUILD_FILE"

giving e.g. ^sonar-java.*\s*=\s*" for plugin-name java. The greedy .* makes this match any TOML key that merely starts with the plugin name. In gradle/libs.versions.toml a line like sonar-javascript = "4.5.6" is matched by sonar-java + .*(script ) + = ", so releasing java would silently rewrite the sonar-javascript (and any other sonar-java*) version to the java release version.

Unlike the Gradle pattern, the TOML pattern has no -plugin: suffix to bound the key, so the collision is much more likely to fire against real sibling entries. Because sed exits 0 even when it edits the wrong line, the bad change is only visible in the resulting PR diff.

Consider anchoring the TOML key so the plugin name must be the full key (no trailing .*), e.g. require the key to be immediately followed by optional whitespace and =.

✅ Quality: sqaa-integration without sqc-integration silently does nothing

📄 .github/workflows/automated-release.yml:806-810 📄 .github/workflows/automated-release.yml:857-859
The update-analyzers job runs when any of sqs-integration || sqc-integration || sqaa-integration is true (lines 806-810), but the update-sqaa step requires both sqaa-integration && sqc-integration (line 859). If a caller enables sqaa-integration: true while leaving sqc-integration: false, the job runs but the SQAA step is skipped with no warning or error, and no SQAA PR is produced. The dependency is only documented in the input description, so a misconfiguration fails silently and is easy to miss.

Consider adding an explicit validation step (or a warning) that fails/notifies when sqaa-integration is true but sqc-integration is false, making the misconfiguration visible.

Options ✅ Auto-apply

✅ Auto-apply is on → Gitar will commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

✅ Auto-apply	Compact
gitar auto-apply:off	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[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