ci: cancel superseded workflow runs and bump anchore-scan action

[esarafianou]

Summary

• .github/workflows/ci.yml — add a top-level concurrency block (group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true). On PR Update golang version to 1.26.3 #461 we observed three runs (Add Anchore Scan in CD #433/Bump github/codeql-action from 3.30.6 to 4.30.8 in the github-actions-updates group #434/"db opened", advice to get to next step? #435) all in progress for the same branch; with this block, new pushes on a PR branch supersede their in-flight predecessors while pushes to master and tag refs remain isolated (each gets its own ref-scoped group).
• .github/workflows/cd.yml — bump mattermost/actions/delivery/anchore-scan from 003fac68730de6e3e2dc31939e7f2c460f2a8ba0 to 354df0f666759a18085c7c7135db533f6b1da367 (current HEAD of mattermost/actions, "Update anchorectl to match instance version (update olm #56)", 2026-05-20). Both anchore-operator and anchore-operator-fips steps updated to keep the pinned SHA current.

NONE

Made with Cursor

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a339214a-5afe-41b4-8054-e0a83e9eeb74

📥 Commits

Reviewing files that changed from the base of the PR and between 19d54f9 and c99d0a5.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

---

📝 Walkthrough

Walkthrough

CD workflow: pins the Anchore scan action to a new mattermost/actions/delivery/anchore-scan commit for both standard and FIPS steps. CI workflow: adds a top-level concurrency block grouping runs by workflow+ref and conditionally cancels in-progress runs for pull_request events.

Changes

Workflow Configuration Updates

Layer / File(s)	Summary
Anchore action version bump .github/workflows/cd.yml	security/anchore-scan and security/anchore-scan-fips steps now reference a new pinned commit of the mattermost/actions/delivery/anchore-scan action; all step inputs remain unchanged.
CI workflow concurrency policy .github/workflows/ci.yml	Top-level concurrency block added to group runs by ${{ github.workflow }}-${{ github.ref }} and cancel in-progress runs when the event is a pull_request.

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes both main changes: adding workflow concurrency policy to cancel superseded runs and bumping the anchore-scan action.
Description check	✅ Passed	The description provides detailed context for both changes, including specific commit hashes, the rationale for the concurrency policy, and references to related issues.
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.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/workflow-hardening

---

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

[NARSimoes]

Thanks @esarafianou , just a minor clarification

[NARSimoes]

Just a sanity check: with the current configuration each new push to master cancels the previous in-progress ci run on refs/heads/master, because they share one concurrency group and cancel-in-progress: true. So, this can happens if we fast merge multiple pull-request which might affect some docker pushes that we do in CI. If this is accurate I wonder if we should just cancel in pull-request (e.g. cancel-in-progress: ${{ github.event_name == 'pull_request' }}).

[esarafianou]

Good catch, addressing now.