Conversation
- `edge` for latest built from main branch - `latest` for latest released (versioned) one; unless it’s a pre–release
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe changes update two GitHub Actions workflow YAML files. The first file standardizes quote usage and whitespace formatting without altering logic. The second file refines version parsing logic, introduces pre-release detection, updates tagging behavior, and removes an unused environment variable, alongside minor formatting improvements. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/reusable-release.yml(3 hunks).github/workflows/reusable-tag-docker-release-images.yml(2 hunks)
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: marek-saji
PR: verkstedt/actions#20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.853Z
Learning: In GitHub Actions Docker build workflows, referencing non-existent step outputs in the tags field of docker/build-push-action@v6 does not cause build failures - the action handles missing tag references gracefully.
Learnt from: marek-saji
PR: verkstedt/actions#20
File: .github/workflows/create-release-pr.yaml:64-67
Timestamp: 2025-07-22T11:11:35.634Z
Learning: In GitHub Actions workflows, `${{ toJson(inputs.release_type) }}` interpolation happens before JavaScript parsing. For string inputs, toJson() produces quoted strings that become valid JavaScript string literals (e.g., `const releaseType = "patch";`), so switch statements work correctly with case branches like `case 'patch':`.
Learnt from: marek-saji
PR: verkstedt/actions#20
File: .github/workflows/docker-build-push.yaml:128-161
Timestamp: 2025-07-22T12:27:24.399Z
Learning: GitHub Actions runs shell scripts with `bash --noprofile --norc -eo pipefail {0}` by default, which provides exit-on-error (-e) and pipeline-failure-detection (-o pipefail) flags, making additional `set -euo pipefail` unnecessary in workflow scripts.
Learnt from: marek-saji
PR: verkstedt/actions#20
File: .github/workflows/docker-build-push.yaml:236-255
Timestamp: 2025-07-22T12:12:09.068Z
Learning: In GitHub Actions Docker workflows, intentionally using separate docker/build-push-action steps (one with push: false for building, followed by another with push: true) can be a deliberate design choice to provide timing visibility and show how much time is spent on each phase, rather than being a performance oversight.
.github/workflows/reusable-release.yml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/create-release-pr.yaml:64-67
Timestamp: 2025-07-22T11:11:35.634Z
Learning: In GitHub Actions workflows, ${{ toJson(inputs.release_type) }} interpolation happens before JavaScript parsing. For string inputs, toJson() produces quoted strings that become valid JavaScript string literals (e.g., const releaseType = "patch";), so switch statements work correctly with case branches like case 'patch':.
.github/workflows/reusable-tag-docker-release-images.yml (2)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.853Z
Learning: In GitHub Actions Docker build workflows, referencing non-existent step outputs in the tags field of docker/build-push-action@v6 does not cause build failures - the action handles missing tag references gracefully.
Learnt from: marek-saji
PR: #20
File: .github/workflows/create-release-pr.yaml:64-67
Timestamp: 2025-07-22T11:11:35.634Z
Learning: In GitHub Actions workflows, ${{ toJson(inputs.release_type) }} interpolation happens before JavaScript parsing. For string inputs, toJson() produces quoted strings that become valid JavaScript string literals (e.g., const releaseType = "patch";), so switch statements work correctly with case branches like case 'patch':.
🔇 Additional comments (3)
.github/workflows/reusable-tag-docker-release-images.yml (2)
64-66: Good move to use anchored regex for stripping the leadingv.The previous naive replacement risked deleting the first internal
vas well, so this change is spot-on.
75-77: 👍 Skiplatestfor pre-releases.The
latestpointer no longer advances for-rc/-betaversions, avoiding accidental upgrades in production pulls. Nice touch..github/workflows/reusable-release.yml (1)
6-12: Quote-style change only – no functional impact.The switch to single quotes keeps description strings consistent across workflows.
Why?
We used
releasetag for last build onmain, which was a mistake and confusing.What?
New convention is:
edgefor latest built from main branchlatestfor latest released (versioned) one; unless it’s a pre–releaseAlso drops
GOOGLE_ARTIFACT_REGISTRY_DEFAULT_TAGin favour of hard–codingthese tags to force uniformity across projects.