ci(tests): fix OCIR registry login in Release E2E workflow - #2973
Conversation
The Release E2E build job referenced secrets OCI_REGISTRY_USERNAME / OCI_REGISTRY_PASSWORD, which do not exist in the repo, so docker/login-action received empty credentials and failed every run with "Username and password required". The workflow has never built since it was added (2026-05-02): v1.5.0-rc.2, v1.5.0-rc.3 and v1.5.0 all died at this step before any image was built or test run. Use the configured OCIR_USER / OCIR_TOKEN secrets, matching build-main.yaml and pull-requests.yaml, and isolate the Docker config per job (Set up Docker config step + DOCKER_CONFIG on the login and build steps) so login does not clobber the shared ~/.docker/config.json on the self-hosted runner. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
📝 WalkthroughWalkthroughThe release E2E workflow's ChangesRelease E2E Docker config isolation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 @.github/workflows/release-e2e.yaml:
- Line 46: The `docker/login-action@v3` on line 46 uses a mutable version tag
which violates security best practices and can lead to supply-chain attacks.
Replace the mutable tag `v3` with a full commit SHA (following the same pattern
already used in codeql.yml) to ensure the workflow uses an immutable, specific
version of the action.
🪄 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: Pro
Run ID: 6c409bd1-cf0e-4091-8293-e50d67fc1a5c
📒 Files selected for processing (1)
.github/workflows/release-e2e.yaml
| fi | ||
|
|
||
| - name: Login to registry | ||
| uses: docker/login-action@v3 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, examine the file to confirm line 46 content
cat -n .github/workflows/release-e2e.yaml | sed -n '40,55p'Repository: cozystack/cozystack
Length of output: 627
🏁 Script executed:
# Check if there are other workflows to see the pattern consistency
fd -e yaml .github/workflows/ -x grep -l "docker/login-action" {}Repository: cozystack/cozystack
Length of output: 441
🏁 Script executed:
# Look for any pinning policy or security documentation
fd -e md -e txt . | xargs grep -l "pin\|commit.*sha\|docker/login" 2>/dev/null | head -20Repository: cozystack/cozystack
Length of output: 579
🌐 Web query:
docker/login-action v3 mutable tag vs commit sha pinning security best practices
💡 Result:
The use of immutable commit SHA pinning for GitHub Actions, including docker/login-action, is widely considered the industry security best practice to prevent supply chain attacks [1][2][3]. Security Best Practices: 1. Use Immutable Commit SHAs: Unlike version tags (e.g., v3), which are mutable and can be retargeted by maintainers or attackers to point to malicious code, full 40-character commit SHAs are content-addressable and immutable [1][2][4]. Pinning to a specific SHA ensures your workflow executes the exact code you have reviewed and verified [5][4]. 2. Mitigating Tag Retargeting: If an attacker compromises a repository or an account with push access, they can update existing tags to point to compromised commits [6][7]. SHA pinning renders this attack vector ineffective because the workflow will continue to reference the original, verified commit hash [1][5]. 3. Organizational Policy Enforcement: Many organizations now enforce SHA pinning at the policy level [3][4]. GitHub allows administrators to mandate full commit SHA pinning for all actions; when enabled, workflows using tags will fail execution [2][3][4]. 4. Maintenance Strategy: To balance security with the need for updates, teams commonly use automated dependency management tools like Dependabot or Renovate [1][7][5]. These tools can be configured to automatically create pull requests that update SHAs, while preserving the human-readable version tag (e.g., v3) in a code comment [5][4]. This allows for easy tracking and controlled adoption of new versions [1][7]. Implementation Example: When pinning, use the full 40-character SHA and include a comment with the original version for readability [1][5]. - uses: docker/login-action@f4b8f3e # v3.3.0 While tags are more convenient and widely used, they should only be used if you fully trust the creator and are aware of the risks associated with mutability [2]. For enterprise or production-grade CI/CD pipelines, SHA pinning is the standard requirement [2][3][4].
Citations:
- 1: https://docs.ozarksecuritylabs.com/supply-chain/tier-1-baseline/sha-pin-actions/
- 2: https://docs.github.com/en/actions/reference/security/secure-use
- 3: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
- 6: Krunixbase/agent-ai-lab@690a52c
- 7: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
🏁 Script executed:
# Find all workflow files and check for unpinned docker/login-action uses
fd --full-path '.github/workflows' -type f -name '*.yaml' -o -name '*.yml' | xargs grep -n "docker/login-action" 2>/dev/nullRepository: cozystack/cozystack
Length of output: 236
🌐 Web query:
docker/login-action v3 latest commit sha
💡 Result:
docker/login-action@v3 latest commit SHA (i.e., the current HEAD of the v3 branch as of 2026-06-22): 06895751d15a223ec091bea144ad5c7f50d228d0 [1]. Notes: GitHub actions “めら (@V3)” points to the moving tag/branch for major version v3; the commit SHA shown for the v3 tree is 06895751d15a223ec091bea144ad5c7f50d228d0. [1]
Citations:
🏁 Script executed:
# Correct fd syntax to find all yaml files in .github/workflows
fd . '.github/workflows' -type f \( -name '*.yaml' -o -name '*.yml' \)Repository: cozystack/cozystack
Length of output: 234
🏁 Script executed:
# Then check them for docker/login-action and other action uses
find .github/workflows -type f \( -name '*.yaml' -o -name '*.yml' \) -exec grep -n "uses:" {} + | head -30Repository: cozystack/cozystack
Length of output: 2582
Pin docker/login-action to a commit SHA instead of a mutable tag.
Line 46 uses docker/login-action@v3, which is mutable and violates workflow hardening best practices. Pin this to a full commit SHA to prevent upstream tag retargeting and supply-chain attacks. This repo already practices SHA pinning in codeql.yml; apply the same pattern here for consistency.
Suggested change
- name: Login to registry
- uses: docker/login-action@v3
+ uses: docker/login-action@06895751d15a223ec091bea144ad5c7f50d228d0 # v3📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: docker/login-action@v3 | |
| uses: docker/login-action@06895751d15a223ec091bea144ad5c7f50d228d0 # v3 |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 46-46: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 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 @.github/workflows/release-e2e.yaml at line 46, The `docker/login-action@v3`
on line 46 uses a mutable version tag which violates security best practices and
can lead to supply-chain attacks. Replace the mutable tag `v3` with a full
commit SHA (following the same pattern already used in codeql.yml) to ensure the
workflow uses an immutable, specific version of the action.
Source: Linters/SAST tools
## What this PR does Removes the `Release E2E` workflow (`.github/workflows/release-e2e.yaml`), which ran the full bats suite on every release tag. **Why it's redundant.** `release-e2e.yaml` was a non-blocking alarm — its own header states *"a failure here is an alarm, not a release blocker."* The coverage it provided is already delivered by the release-cut PR: the "Prepare release" commit bakes image digests into `packages/core/` (installer, platform, testing) and other packages, and `select-e2e.sh`'s full-suite pattern escalates any `packages/core/` change to the **full** suite. So the release PR already runs the whole suite against the commit the tag will point at. **Why now.** The workflow has never been green since it was added (2026-05-02) — every tag run (`v1.5.0-rc.2`, `-rc.3`, `v1.5.0`) failed at the build step. Even after #2973 fixed the registry login earlier today, the next run still failed at *Build Talos image*. A perpetually-red, non-gating duplicate is pure noise. **Changes** - Delete `.github/workflows/release-e2e.yaml`. - Drop `release-e2e` from the full-suite pattern in `hack/select-e2e.sh`. - Repoint the workflow-trigger unit test in `hack/select-e2e_test.bats` to `pull-requests.yaml` (the remaining E2E workflow), preserving "workflow edit → full suite" coverage. All 11 `select-e2e_test.bats` cases pass. - Update `docs/agents/e2e-testing.md` to describe the release-cut PR as where the full suite runs. Refs #2397. ### Release note ```release-note ci(tests): remove the redundant Release E2E workflow; the full E2E suite already runs on the release-cut PR ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Removed automated release end-to-end testing workflow * Updated E2E test selection logic to reflect testing infrastructure changes * **Documentation** * Updated E2E testing procedures documentation to reflect current testing approach <!-- end of auto-generated comment: release notes by coderabbit.ai -->
The Release E2E workflow (`release-e2e.yaml`) ran the full bats suite on every release tag as a non-blocking alarm — its own header notes "a failure here is an alarm, not a release blocker." It duplicates coverage the release-cut PR already provides: the "Prepare release" commit bakes image digests into `packages/core/` (and other packages), which TIA escalates to the full suite, so the release PR exercises the whole suite against the commit the tag will point at. It has also never been green since it was added (2026-05-02): every tag run failed at the build step. Even after cozystack#2973 fixed the registry login today, the next run still failed (Build Talos image). Removing a perpetually-red, non-gating duplicate removes noise without losing coverage. Removes the workflow, drops `release-e2e` from `select-e2e.sh`'s full-suite pattern, repoints its unit test to `pull-requests.yaml`, and updates the e2e-testing doc. Refs cozystack#2397 Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
What this PR does
The
Release E2Eworkflow's build job logged intoiad.ocir.iousingsecrets.OCI_REGISTRY_USERNAME/secrets.OCI_REGISTRY_PASSWORD— secret names that don't exist in the repo.docker/login-actiontherefore received empty credentials and failed at the very first step withUsername and password required, before any image was built or any test ran.The workflow has never succeeded since it was added (2026-05-02): all three tag runs to date died at this step —
v1.5.0-rc.2,v1.5.0-rc.3, andv1.5.0.This switches the login to the configured
OCIR_USER/OCIR_TOKENsecrets — the same onesbuild-main.yamlandpull-requests.yamluse against the same registry — and adds the per-job Docker config isolation those workflows already use (Set up Docker configstep +DOCKER_CONFIGenv on the login and build steps), so the login doesn't clobber the shared~/.docker/config.jsonon the self-hosted runner.Release note
Summary by CodeRabbit
Release Notes