Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Note Reviews pausedUse the following commands to manage reviews:
📝 WalkthroughSummary by CodeRabbit
WalkthroughSeveral new GitHub Actions workflow files were introduced to automate release, Docker image build and push, and commit comment referencing processes. Existing workflows received minor updates for quoting environment variables, shellcheck directives, and error message formatting. Documentation was updated to reference the new workflows, and Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHub Actions
participant GitHub API
participant Docker Registry
participant AWS ECR
participant Google Artifact Registry
Developer->>GitHub Actions: Trigger workflow (manual or push)
GitHub Actions->>GitHub Actions: Checkout repo, extract version info
GitHub Actions->>GitHub API: Generate release notes, check tags
alt Release PR Workflow
GitHub Actions->>GitHub Actions: Bump version, update changelog
GitHub Actions->>GitHub API: Create PR with release notes
else Docker Build/Push Workflow
GitHub Actions->>Docker Registry: Build & push image (GHCR)
opt If AWS enabled
GitHub Actions->>AWS ECR: Push image
end
opt If Google enabled
GitHub Actions->>Google Artifact Registry: Push image
end
alt Version changed
GitHub Actions->>GitHub API: Create git tag & release
end
end
Estimated code review effort4 (~75 minutes) Poem
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/docker-build-and-push.yml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/docker-build-and-push.yml
[warning] 2-2: truthy value should be one of [false, true]
(truthy)
[error] 18-18: trailing spaces
(trailing-spaces)
[error] 32-32: trailing spaces
(trailing-spaces)
[error] 54-54: trailing spaces
(trailing-spaces)
[error] 64-64: trailing spaces
(trailing-spaces)
[error] 189-189: trailing spaces
(trailing-spaces)
[error] 228-228: trailing spaces
(trailing-spaces)
[error] 248-248: trailing spaces
(trailing-spaces)
[error] 256-256: trailing spaces
(trailing-spaces)
[error] 273-273: trailing spaces
(trailing-spaces)
[error] 284-284: trailing spaces
(trailing-spaces)
[error] 289-289: trailing spaces
(trailing-spaces)
[error] 295-295: trailing spaces
(trailing-spaces)
[error] 302-302: trailing spaces
(trailing-spaces)
[error] 310-310: trailing spaces
(trailing-spaces)
[error] 366-366: trailing spaces
(trailing-spaces)
[error] 374-374: trailing spaces
(trailing-spaces)
[error] 382-382: trailing spaces
(trailing-spaces)
[error] 392-392: trailing spaces
(trailing-spaces)
[error] 404-404: trailing spaces
(trailing-spaces)
[error] 410-410: trailing spaces
(trailing-spaces)
[error] 415-415: no new line character at the end of file
(new-line-at-end-of-file)
[error] 415-415: trailing spaces
(trailing-spaces)
🔇 Additional comments (1)
.github/workflows/docker-build-and-push.yml (1)
328-331: VerifyGOOGLE_REPOSITORYfallback doesn’t evaluate to empty
If bothinputs.google_repositoryandvars.GOOGLE_ARTIFACT_REGISTRY_REPOSITORYare unset, the job proceeds with an empty repository path and will fail on push. Confirm callers always provide one of the two, or add a guard that fails early with a descriptive message.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (5)
.github/workflows/docker-build-and-push.yml (5)
2-3: Quoteonto silence YAML-1.1 “truthy” warnings
on:is parsed as a boolean by YAML-1.1 linters. Wrap the key in single quotes.
18-18: Remove trailing whitespace – fails YAMLlint
Numerous lines still contain trailing spaces, producing YAMLlint errors and noisy diffs. Strip the blanks.Also applies to: 32-32, 54-54, 64-64, 70-70, 197-197, 236-236, 256-256, 264-264, 281-281, 292-292, 297-297, 303-303, 310-310, 318-318, 374-374, 382-382, 390-390, 400-400, 412-412, 418-418, 423-423
152-153: Pass tags as newline-separated list for Buildx readability
Buildx accepts commas, but newlines are the documented, more readable format.
221-225: Missingecr: trueandregion– ECR login will errorWithout these parameters
docker/login-actiontreats the registry as generic Docker Hub and fails with “no auth data provided”.
226-238:REPO_NAMEis undefined in the else-branchWhen
inputs.ecr_repositoryis provided, the script writes the output but never assignsREPO_NAME, leading to an empty${REPO_NAME}when composingFULL_PATH.else - echo "name=${{ inputs.ecr_repository }}" >> $GITHUB_OUTPUT + REPO_NAME='${{ inputs.ecr_repository }}' + echo "name=$REPO_NAME" >> $GITHUB_OUTPUT fi FULL_PATH="${{ inputs.ecr_registry }}/$REPO_NAME"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/docker-build-and-push.yml(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/docker-build-and-push.yml
[warning] 2-2: truthy value should be one of [false, true]
(truthy)
[error] 18-18: trailing spaces
(trailing-spaces)
[error] 32-32: trailing spaces
(trailing-spaces)
[error] 54-54: trailing spaces
(trailing-spaces)
[error] 64-64: trailing spaces
(trailing-spaces)
[error] 70-70: trailing spaces
(trailing-spaces)
[error] 197-197: trailing spaces
(trailing-spaces)
[error] 236-236: trailing spaces
(trailing-spaces)
[error] 256-256: trailing spaces
(trailing-spaces)
[error] 264-264: trailing spaces
(trailing-spaces)
[error] 281-281: trailing spaces
(trailing-spaces)
[error] 292-292: trailing spaces
(trailing-spaces)
[error] 297-297: trailing spaces
(trailing-spaces)
[error] 303-303: trailing spaces
(trailing-spaces)
[error] 310-310: trailing spaces
(trailing-spaces)
[error] 318-318: trailing spaces
(trailing-spaces)
[error] 374-374: trailing spaces
(trailing-spaces)
[error] 382-382: trailing spaces
(trailing-spaces)
[error] 390-390: trailing spaces
(trailing-spaces)
[error] 400-400: trailing spaces
(trailing-spaces)
[error] 412-412: trailing spaces
(trailing-spaces)
[error] 418-418: trailing spaces
(trailing-spaces)
[error] 423-423: no new line character at the end of file
(new-line-at-end-of-file)
[error] 423-423: trailing spaces
(trailing-spaces)
🔇 Additional comments (1)
.github/workflows/docker-build-and-push.yml (1)
241-246:push_ecrdepends on an image that may not exist remotely
push_ecralways pulls${{ needs.docker_build.outputs.image }}, which is only pushed whenpush_to_githubistrue.
If users setpush_to_github: false&push_to_ecr: true, this job will fail.
Either enforcepush_to_githubwhen ECR push is requested, or copy from the local build artefact instead.
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
| repo: context.repo.repo, | ||
| title: `Release ${newVersion}`, | ||
| head: branchName, | ||
| base: 'test-github-actions', // DEBUG TODO Change to main when ready |
There was a problem hiding this comment.
❗ Remember to change to main before merging.
There was a problem hiding this comment.
Actionable comments posted: 7
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/create-release-pr.yaml(1 hunks).github/workflows/docker-build-push.yaml(1 hunks)README.md(1 hunks)
🪛 LanguageTool
README.md
[grammar] ~176-~176: Use correct spacing
Context: ...rom said comment. ### Docker Build and Push Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~181-~181: Use the right pronoun
Context: ...uild-push.yaml> Build docker image and push to registries. When version change is d...
(QB_NEW_EN_OTHER_ERROR_IDS_9)
[grammar] ~181-~181: Use articles correctly
Context: ...cker image and push to registries. When version change is detected, also create git tag...
(QB_NEW_EN_OTHER_ERROR_IDS_11)
[grammar] ~181-~181: Use articles correctly
Context: .... When version change is detected, also create git tag. See [docker-build-push.yaml](....
(QB_NEW_EN_OTHER_ERROR_IDS_11)
[grammar] ~181-~181: Use correct spacing
Context: ...ion change is detected, also create git tag. See [docker-build-push.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~183-~183: Use correct spacing
Context: ...b/workflows/docker-build-push.yaml) for details. ### Create Release PR Template: <https://gi...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~185-~185: Use correct spacing
Context: ....yaml) for details. ### Create Release PR Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~190-~190: Use correct spacing
Context: ...pr.yaml> Create a PR that bumps up the version. See [create-release-pr.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~192-~192: Use correct spacing
Context: ...b/workflows/docker-build-push.yaml) for details. ## Deploying new versions of actions and wo...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🧰 Additional context used
🪛 LanguageTool
README.md
[grammar] ~176-~176: Use correct spacing
Context: ...rom said comment. ### Docker Build and Push Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~181-~181: Use the right pronoun
Context: ...uild-push.yaml> Build docker image and push to registries. When version change is d...
(QB_NEW_EN_OTHER_ERROR_IDS_9)
[grammar] ~181-~181: Use articles correctly
Context: ...cker image and push to registries. When version change is detected, also create git tag...
(QB_NEW_EN_OTHER_ERROR_IDS_11)
[grammar] ~181-~181: Use articles correctly
Context: .... When version change is detected, also create git tag. See [docker-build-push.yaml](....
(QB_NEW_EN_OTHER_ERROR_IDS_11)
[grammar] ~181-~181: Use correct spacing
Context: ...ion change is detected, also create git tag. See [docker-build-push.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~183-~183: Use correct spacing
Context: ...b/workflows/docker-build-push.yaml) for details. ### Create Release PR Template: <https://gi...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~185-~185: Use correct spacing
Context: ....yaml) for details. ### Create Release PR Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~190-~190: Use correct spacing
Context: ...pr.yaml> Create a PR that bumps up the version. See [create-release-pr.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~192-~192: Use correct spacing
Context: ...b/workflows/docker-build-push.yaml) for details. ## Deploying new versions of actions and wo...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
marek-saji
changed the title
marek-saji
force-pushed
the
new-actions-for-building-pushing-and-releasing
branch
from
b317bfd to
554bf6d
Compare
Refs #20 (comment)
Refs #20 (comment) Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (2)
.github/workflows/notify-main-branch-failure.yaml (1)
33-33: Same phantom ShellCheck rule as in chromatic workflow
# shellcheck disable=SC1111refers to a non-existent rule (see comment in chromatic workflow).
Consider removing it.README.md (1)
176-183: Minor wording & number-agreement polishPlural-singular mismatch (“image … registries”) and missing pronoun make the sentence awkward.
-Build Docker image and push it to the registries. When a version change is detected, also create a git tag. +Build Docker images and push them to the registries. When a version change is detected, also create a git tag.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/chromatic.yaml(1 hunks).github/workflows/ci.yaml(2 hunks).github/workflows/docker-build-push.yaml(1 hunks).github/workflows/jira.yaml(1 hunks).github/workflows/notify-main-branch-failure.yaml(1 hunks)README.md(1 hunks)
🧠 Learnings (6)
📓 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.791Z
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.
.github/workflows/notify-main-branch-failure.yaml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
.github/workflows/ci.yaml (2)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.603Z
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':.
README.md (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
.github/workflows/jira.yaml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
.github/workflows/docker-build-push.yaml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
🪛 LanguageTool
README.md
[grammar] ~176-~176: Use correct spacing
Context: ...rom said comment. ### Docker Build and Push Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~181-~181: Use articles correctly
Context: ...emplates/docker-build-push.yaml> Build Docker image and push it to the registries. Wh...
(QB_NEW_EN_OTHER_ERROR_IDS_11)
[grammar] ~181-~181: Use correct spacing
Context: ...n change is detected, also create a git tag. See [docker-build-push.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~183-~183: Use correct spacing
Context: ...b/workflows/docker-build-push.yaml) for details. ### Create Release PR Template: <https://gi...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~185-~185: Use correct spacing
Context: ....yaml) for details. ### Create Release PR Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~190-~190: Use correct spacing
Context: ...pr.yaml> Create a PR that bumps up the version. See [create-release-pr.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🧰 Additional context used
🧠 Learnings (6)
📓 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.791Z
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.
.github/workflows/notify-main-branch-failure.yaml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
.github/workflows/ci.yaml (2)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.603Z
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':.
README.md (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
.github/workflows/jira.yaml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
.github/workflows/docker-build-push.yaml (1)
Learnt from: marek-saji
PR: #20
File: .github/workflows/docker-build-push.yaml:240-242
Timestamp: 2025-07-22T11:18:25.791Z
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.
🪛 LanguageTool
README.md
[grammar] ~176-~176: Use correct spacing
Context: ...rom said comment. ### Docker Build and Push Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~181-~181: Use articles correctly
Context: ...emplates/docker-build-push.yaml> Build Docker image and push it to the registries. Wh...
(QB_NEW_EN_OTHER_ERROR_IDS_11)
[grammar] ~181-~181: Use correct spacing
Context: ...n change is detected, also create a git tag. See [docker-build-push.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~183-~183: Use correct spacing
Context: ...b/workflows/docker-build-push.yaml) for details. ### Create Release PR Template: <https://gi...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~185-~185: Use correct spacing
Context: ....yaml) for details. ### Create Release PR Template: <https://github.com/verkstedt/...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
[grammar] ~190-~190: Use correct spacing
Context: ...pr.yaml> Create a PR that bumps up the version. See [create-release-pr.yaml](./.github/w...
(QB_NEW_EN_OTHER_ERROR_IDS_5)
🔇 Additional comments (4)
.github/workflows/chromatic.yaml (1)
27-28: SC1111 is a real ShellCheck rule—Unicode quotes trigger it
ShellCheck SC1111 warns about curly/“smart” quotes and is correctly disabled here to allow the Unicode characters in the message.
- The quotes around “Manage” and “Configure” are Unicode characters, which SC1111 flags.
- If you want to keep the fancy curly quotes in your output, retaining
# shellcheck disable=SC1111is appropriate.- If you prefer standard ASCII quotes instead, you can replace the curly quotes with straight
"and drop the disable line.Likely an incorrect or invalid review comment.
.github/workflows/jira.yaml (1)
15-37: Looks good – messages switched to stderr consistentlyThe transition to plain
echowith1>&2is consistent and no functional issues spotted..github/workflows/ci.yaml (2)
40-62: Good catch on quoting$ENV_VARSQuoting fixes word-splitting edge cases; no further issues spotted.
313-317: Unquoted secret may break multi-line env injection
secrets.build_envcan contain spaces/newlines. For consistency with the new quoting everywhere else, quote this echo:- echo "${{ secrets.build_env }}" >> "$GITHUB_ENV" + echo "${{ secrets.build_env }}" >> "$GITHUB_ENV"(Only quoting change – the example shows identical content because of interpolation; the important part is to wrap the variable in double-quotes.)
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (1)
README.md (1)
176-183: Polish wording: singular → pluralSame wording issue as noted previously: use plural “images” and pronoun “them”.
-Build Docker image and push it to the registries. +Build Docker images and push them to the registries.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/ci.yaml(3 hunks).github/workflows/docker-build-push.yaml(1 hunks).github/workflows/notify-main-branch-failure.yaml(1 hunks).github/workflows/ref-comment-in-commit.yaml(1 hunks).gitignore(1 hunks)README.md(1 hunks)
🧠 Learnings (6)
📓 Common learnings
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.
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/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.
.github/workflows/notify-main-branch-failure.yaml (2)
Learnt from: marek-saji
PR: #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: #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.
README.md (2)
Learnt from: marek-saji
PR: #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.
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.
.github/workflows/ref-comment-in-commit.yaml (1)
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.
.github/workflows/ci.yaml (3)
Learnt from: marek-saji
PR: #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: #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/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/docker-build-push.yaml (3)
Learnt from: marek-saji
PR: #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.
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/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.
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
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.
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/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.
.github/workflows/notify-main-branch-failure.yaml (2)
Learnt from: marek-saji
PR: #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: #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.
README.md (2)
Learnt from: marek-saji
PR: #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.
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.
.github/workflows/ref-comment-in-commit.yaml (1)
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.
.github/workflows/ci.yaml (3)
Learnt from: marek-saji
PR: #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: #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/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/docker-build-push.yaml (3)
Learnt from: marek-saji
PR: #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.
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/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.
🔇 Additional comments (4)
.gitignore (1)
2-3: 👍 Sensible ignore rule addedIgnoring the
.vscodefolder is a common-sense addition and prevents committing local editor settings.
No further issues spotted..github/workflows/ref-comment-in-commit.yaml (1)
1-23: Workflow looks goodSyntax, indentation and token usage are all correct. Nothing to flag.
.github/workflows/ci.yaml (1)
41-42: Quote$GITHUB_ENVwrites already – 👍Thank you for adding the quotes; this prevents word-splitting issues when
env_varscontains spaces or newlines..github/workflows/docker-build-push.yaml (1)
145-147: Remote refs aren’t available after the shallow fetch
git fetch origin "${PREVIOUS_GIT_REF}" --depth=1downloads the commit, but you subsequently reference the ref without theorigin/prefix.
For branch names (e.g.main) this meansgit show main:package.jsonresolves to the local branch (the current checkout), not the fetched remote branch.git fetch origin "${PREVIOUS_GIT_REF}" --depth=1 OLD_VERSION="$(git show "FETCH_HEAD:package.json" 2>/dev/null | jq -r '.version')"Using
FETCH_HEAD(or explicitlyorigin/${PREVIOUS_GIT_REF}) guarantees you compare against the intended reference.
marek-saji
force-pushed
the
new-actions-for-building-pushing-and-releasing
branch
from
ace082f to
02ea9a4
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (5)
.github/workflows/create-release-pr.yaml (2)
51-55: Workflow aborts on very first releaseExiting with code 65 when the previous tag is not found prevents boot-strapping a repo that has never been version-tagged.
- if ! git ls-remote --tags origin "$OLD_VERSION_GIT_TAG" &>/dev/null - then - echo "::error::Previous version tag $OLD_VERSION_GIT_TAG not found." 2>&1 - exit 65 # EX_DATAERR - fi + if ! git ls-remote --tags origin "$OLD_VERSION_GIT_TAG" &>/dev/null + then + echo "::warning::Previous version tag $OLD_VERSION_GIT_TAG not found – assuming first release." + OLD_VERSION_GIT_TAG="" + fi
231-232: Hard-codedbasebranch blocks real releases
base: 'test-github-actions'looks temporary. Merging will try to open PRs against a non-default branch in production repos.- base: 'test-github-actions', // DEBUG TODO Change to main when ready + # Consider making this configurable or defaulting to the repo’s + # default branch. + base: 'main',.github/workflows/docker-build-push.yaml (3)
147-152:git showstill aborts the step when ref/file is missing
([duplicate of earlier review, still unresolved)With
bash -e(default in Actions) a failinggit showstops the script before your manual check. Guard it so the step reaches the emptiness test.-OLD_VERSION="$(git show "${PREVIOUS_GIT_REF}":package.json 2>/dev/null | jq -r '.version')" +OLD_VERSION="$( + git show "${PREVIOUS_GIT_REF}":package.json 2>/dev/null || true +)" || true +OLD_VERSION="$(echo "$OLD_VERSION" | jq -r '.version' 2>/dev/null || true)"
399-400: Possible double “//” in ECR repository URL
(duplicate of a prior nitpick – still present)If
amazon_ecr_registryends with/,${AMAZON_ECR_REGISTRY}/$REPO_NAMEyields…//repo.-FULL_PATH="${AMAZON_ECR_REGISTRY}/$REPO_NAME" +FULL_PATH="$(echo "${AMAZON_ECR_REGISTRY}" | sed 's:/*$::')/${REPO_NAME}"
499-511: Missing validation forgoogle_repositoryleads to invalid tags
(duplicate – previously flagged)When
inputs.google_repositoryis empty the loop produces":edge"tags and the push fails. Validate early.if [ -z "${GOOGLE_REPOSITORY}" ]; then echo "::error::google_repository input must be set when google_enable=true." >&2 exit 64 fi
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
.github/workflows/chromatic.yaml(1 hunks).github/workflows/ci.yaml(2 hunks).github/workflows/create-release-pr.yaml(1 hunks).github/workflows/docker-build-push.yaml(1 hunks).github/workflows/notify-main-branch-failure.yaml(1 hunks)
🧠 Learnings (6)
📓 Common learnings
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.
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/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/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/chromatic.yaml (1)
Learnt from: marek-saji
PR: #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.
.github/workflows/ci.yaml (4)
Learnt from: marek-saji
PR: #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: #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':.
Learnt from: marek-saji
PR: #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/notify-main-branch-failure.yaml (2)
Learnt from: marek-saji
PR: #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: #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.
.github/workflows/create-release-pr.yaml (2)
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':.
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.
.github/workflows/docker-build-push.yaml (3)
Learnt from: marek-saji
PR: #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.
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/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.
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
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.
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/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/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/chromatic.yaml (1)
Learnt from: marek-saji
PR: #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.
.github/workflows/ci.yaml (4)
Learnt from: marek-saji
PR: #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: #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':.
Learnt from: marek-saji
PR: #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/notify-main-branch-failure.yaml (2)
Learnt from: marek-saji
PR: #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: #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.
.github/workflows/create-release-pr.yaml (2)
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':.
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.
.github/workflows/docker-build-push.yaml (3)
Learnt from: marek-saji
PR: #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.
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/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.
🔇 Additional comments (1)
.github/workflows/ci.yaml (1)
39-42: 👍 Quoting the secret fixes word-splitting edge-casesUsing
echo "$ENV_VARS"instead of the unquoted variant prevents accidental word-splitting and glob expansion. Good catch.Also applies to: 59-62, 106-109, 128-132, 180-183, 321-324
|
I've taken a look a it if I could use it for a https://github.com/verkstedt/sisi-ru and I would think it would be helpful to extract this further into re-usable workflows
so that way I can pick and match whatever I need for my particular project (which might not be suitable the default workflow) |
|
Converting to draft. Will discuss after holiday season. |
…g-pushing-and-releasing
marek-saji
force-pushed
the
new-actions-for-building-pushing-and-releasing
branch
from
fae62c1 to
a73e109
Compare
marek-saji
force-pushed
the
new-actions-for-building-pushing-and-releasing
branch
from
a73e109 to
307834e
Compare
3 participants
docker-build-push-pushmainplatformsha-SHAdevelopmentlatestvVERSIONvMAJOR,vMAJOR.MINORvVERSIONCHANGELOG.md?)create-release-prpackage.jsonCHANGELOG.mdpackage.jsonis not foundOthers
#infrastructure-create-release-pr-actioncreate-release-prtoreleasedocker-build-push-pushto separate action (will probably do)verkstedt/.githubrepository (copy from our testing repo after done testing)TODO