Skip to content

fix: cleanup sonar-* resource groups in CI #46

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Schmarvinius merged 1 commit into from
May 27, 2026
Merged

fix: cleanup sonar-* resource groups in CI #46

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions .github/workflows/pipeline.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ jobs:
name: Cleanup Integration Test Resources
runs-on: ubuntu-latest
timeout-minutes: 10
needs: [integration-tests]
needs: [integration-tests, sonarqube-scan]

@hyperspace-pr-bot hyperspace-pr-bot Bot May 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logic Error: integration-tests-cleanup now blocks on sonarqube-scan, but sonarqube-scan runs a matrix job (integration-tests) is also a matrix job — however more critically, when sonarqube-scan itself fails or is skipped (e.g., the SONARQ_TOKEN secret is missing in a fork), the cleanup job will still be gated and may never run, leaking the itest-* resource groups it was originally responsible for.

The if: always() on line 77 only bypasses needs status requirements in some conditions — specifically, when all needed jobs either succeed, fail, or are skipped. However, if sonarqube-scan is never triggered (e.g., in a workflow that doesn't include that job), this dependency will cause the cleanup job to be skipped entirely rather than running as a safety net.

More importantly, this couples the cleanup of unrelated concerns: integration-tests-cleanup was responsible for cleaning up after integration-tests. Tying it to sonarqube-scan means a SonarQube infrastructure problem blocks itest-* cleanup.

Consider keeping the cleanup job independent of sonarqube-scan (restore needs: [integration-tests]) or using a separate cleanup step within the sonarqube-scan job for the sonar-* resource group.

Suggested change
needs: [integration-tests, sonarqube-scan]
needs: [integration-tests]

Double-check suggestion before committing. Edit this comment for amendments.

Please provide feedback on the review comment by checking the appropriate box:

  • 🌟 Awesome comment, a human might have missed that.
  • ✅ Helpful comment
  • 🤷 Neutral
  • ❌ This comment is not helpful

if: always()
permissions:
contents: read
Expand Down Expand Up @@ -118,10 +118,10 @@ jobs:
const tokenRes = await fetch(tokenUrl+'?'+tokenParams.toString(), {headers:{'Authorization':authHeader}});
const token = JSON.parse(tokenRes.body).access_token;
const headers = {'Authorization':'Bearer '+token, 'AI-Resource-Group':'default'};
const prefix = 'itest-${{ github.run_id }}-${{ github.run_attempt }}';
const prefixes = ['itest-${{ github.run_id }}-${{ github.run_attempt }}', 'sonar-${{ github.run_id }}-${{ github.run_attempt }}'];

@hyperspace-pr-bot hyperspace-pr-bot Bot May 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The sonar-* prefix used in the cleanup script may not match the actual resource group IDs created by the SonarQube scan. The prefix sonar-${{ github.run_id }}-${{ github.run_attempt }} is hardcoded here, but there is no evidence in this diff or the workflow that the sonarqube-scan job (via ./.github/actions/scan-with-sonar) actually creates resource groups with this exact naming pattern.

If the SonarQube action uses a different prefix (e.g., sonarqube-, sq-, or something derived from a different variable), this filter will silently match nothing and not clean up the intended groups — which is the exact problem this PR claims to fix.

The actual resource group naming scheme used by ./.github/actions/scan-with-sonar should be verified and the prefix updated to match exactly.

Please provide feedback on the review comment by checking the appropriate box:

  • 🌟 Awesome comment, a human might have missed that.
  • ✅ Helpful comment
  • 🤷 Neutral
  • ❌ This comment is not helpful

const rgRes = await fetch(apiUrl+'/v2/admin/resourceGroups', {headers});
const groups = JSON.parse(rgRes.body).resources || [];
const toDelete = groups.filter(rg => rg.resourceGroupId && rg.resourceGroupId.startsWith(prefix));
const toDelete = groups.filter(rg => rg.resourceGroupId && prefixes.some(p => rg.resourceGroupId.startsWith(p)));
for (const rg of toDelete) {
const res = await fetch(apiUrl+'/v2/admin/resourceGroups/'+rg.resourceGroupId, {method:'DELETE', headers});
console.log('Delete', rg.resourceGroupId, '->', res.status);
Expand Down
Loading