Upgrade GitHub Actions to latest versions#1792
Upgrade GitHub Actions to latest versions#1792salmanmkc wants to merge 1 commit intoZipstack:mainfrom
Conversation
Signed-off-by: Salman Muin Kayser Chishti <13schishti@gmail.com>
|
|
Summary by CodeRabbitChores
WalkthroughThe pull request updates multiple GitHub Actions workflow files with newer versions of external actions. Changes include upgrading astral-sh/setup-uv to v7, docker build actions to v6, slack-github-action to v2.1.1, git-auto-commit-action to v7, and adding a commit_user_email configuration parameter. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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 |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/docker-tools-build-push.yaml:
- Line 93: The workflow now uses docker/build-push-action@v6 which emits
build-record artifacts by default and can break downstream
actions/download-artifact steps; fix by either setting environment variables on
the docker/build-push-action step (set DOCKER_BUILD_SUMMARY=false and
DOCKER_BUILD_RECORD_UPLOAD=false) to disable record export, or update any
subsequent actions/download-artifact steps to exclude *.dockerbuild artifacts
(use the "name" or "path" filters to skip build-records) so they don't attempt
to download the new build-record files.
In @.github/workflows/production-build.yaml:
- Line 93: The docker/bake-action@v6 step now defaults to Git context and misses
local changes; update the step that uses docker/bake-action@v6 to add a with:
source: . parameter so the action uses the local path context (keep the existing
files, targets, push, and set entries like *.context=. in the Bake config
intact). Locate the action invocation referencing docker/bake-action@v6 and
insert the source: . under its with: block to restore the v5 behavior.
| # Build and push Docker image | ||
| - name: Build and push ${{ github.event.inputs.service_name }} | ||
| uses: docker/build-push-action@v5 | ||
| uses: docker/build-push-action@v6 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
docker/build-push-action v6 breaking changes release notes
💡 Result:
Key v6 change in docker/build-push-action (introduced in v6.0.0, June 17, 2024) is that the action now exports a “build record” and generates a GitHub Actions job “build summary” by default. This can be “breaking” if your workflow later uses actions/download-artifact with default settings (downloads all artifacts), because you must exclude the build-record artifacts (*.dockerbuild) or the download step can fail. You can also disable the feature via env vars (e.g., DOCKER_BUILD_SUMMARY=false; and, separately, DOCKER_BUILD_RECORD_UPLOAD=false). [1][2]
Sources (release notes / docs): [1][2]
🌐 Web query:
docker/build-push-action@v6 inputs context file platforms push tags cache-from cache-to
💡 Result:
docker/build-push-action@v6 inputs (requested ones)
context(String): Build context (PATH or URL). Default is the Git context. [1]file(String): Path to the Dockerfile. Default:{context}/Dockerfile. [1]platforms(List/CSV): Target platforms to build for (e.g.,linux/amd64,linux/arm64). [1]push(Bool): Shorthand for--output=type=registry(push to registry). Default:false. [1]tags(List/CSV): Image tags to apply (newline-delimited or comma-delimited). [1]cache-from(List): External cache sources (e.g.,type=gha,type=local,src=...). [1][2]cache-to(List): Cache export destinations (e.g.,type=gha,mode=max,type=local,dest=...,mode=max). [1][2]
Sources: docker/build-push-action README inputs table [1]; Docker Docs “Cache management” examples for cache-from/cache-to [2].
[1] (github.com)
[2] (docs.docker.com)
Citations:
- 1: https://github.com/docker/build-push-action
- 2: https://docs.docker.com/build/ci/github-actions/cache/?utm_source=openai
Check for downstream actions/download-artifact usage with docker/build-push-action@v6 upgrade
The upgrade to v6 introduces a breaking change: the action now exports build records and generates GitHub Actions job summaries by default. This is only problematic if your workflow uses actions/download-artifact with default settings afterward—it may fail trying to download *.dockerbuild artifacts. Either exclude the build-record artifacts in the download step or disable the feature via environment variables (DOCKER_BUILD_SUMMARY=false and DOCKER_BUILD_RECORD_UPLOAD=false).
🤖 Prompt for AI Agents
In @.github/workflows/docker-tools-build-push.yaml at line 93, The workflow now
uses docker/build-push-action@v6 which emits build-record artifacts by default
and can break downstream actions/download-artifact steps; fix by either setting
environment variables on the docker/build-push-action step (set
DOCKER_BUILD_SUMMARY=false and DOCKER_BUILD_RECORD_UPLOAD=false) to disable
record export, or update any subsequent actions/download-artifact steps to
exclude *.dockerbuild artifacts (use the "name" or "path" filters to skip
build-records) so they don't attempt to download the new build-record files.
| # Build and push using Docker Bake | ||
| - name: Build and push image | ||
| uses: docker/bake-action@v5 | ||
| uses: docker/bake-action@v6 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
docker/bake-action v6 breaking changes release notes
💡 Result:
docker/bake-action v6.0.0 breaking change (release notes):
- Default build context changed to “Git context” (remote git URL based on the triggering ref), aligning behavior with
docker/build-push-action. This can remove the need foractions/checkout, but also means any file changes made earlier in the workflow (including.dockerignorechanges) won’t be seen by the build unless you switch back to a path-based context. [1][2] - If you use
docker/metadata-actionwith Bake and a remote Bake definition, you must use thecwd://prefix to combine the remote definition with a local generated Bake file. [1] - To keep the old (path) behavior, explicitly set
source: .in your workflow step usingdocker/bake-action@v6. [1][2]
Sources: [1] [2]
🏁 Script executed:
cat -n .github/workflows/production-build.yaml | head -120 | tail -50Repository: Zipstack/unstract
Length of output: 2580
🌐 Web query:
docker/bake-action v6 source parameter context setting how to
💡 Result:
In docker/bake-action@v6, there is no separate context: input. You set the build “context” via the action’s source input (and/or via your Bake definition’s target.context). Since v6, if you don’t set source, it defaults to a Git context (https://github.com/<owner>/<repo>.git#<ref>), so you often don’t need actions/checkout. [1]
1) Use the workflow workspace (local path context)
- uses: actions/checkout@v4
- uses: docker/bake-action@v6
with:
source: .
push: trueThis switches from the default Git context to the checked-out files. [1]
2) Use the default Git context, but from a subdirectory
- uses: docker/bake-action@v6
with:
source: "{{defaultContext}}:mysubdir"{{defaultContext}} expands to the default Git context; :mysubdir selects a subdirectory within it. [1]
3) Set/override the context inside the Bake file (recommended for multi-target builds)
In docker-bake.hcl / docker-bake.json, set target.context:
target "app" {
context = "./app"
}target.context is the main build context for that target. [2]
4) Override target.context from the action (no file changes) using set
Because the action’s set: maps to docker buildx bake --set, you can override context like:
- uses: docker/bake-action@v6
with:
source: .
set: |
app.context=./app(set supports target.key=value patterns like target.args...; context is a valid target key in Bake.) [1][2]
If you share your current workflow snippet + bake file, I can point to the exact line to change.
🏁 Script executed:
grep -n "metadata-action" .github/workflows/production-build.yaml || echo "No metadata-action found"Repository: Zipstack/unstract
Length of output: 85
🏁 Script executed:
# Also check the docker-compose.build.yaml structure to understand the bake file
head -50 docker/docker-compose.build.yamlRepository: Zipstack/unstract
Length of output: 1459
Add source: . parameter to docker/bake-action@v6 to restore v5 behavior.
docker/bake-action v6 defaults to Git context instead of local path context. To preserve the old behavior and ensure file modifications in the workflow (like .dockerignore changes) are visible to the build, explicitly set source: . in the action parameters. The current set: *.context=. in the Bake configuration does not override this action-level default.
Suggested fix:
- uses: docker/bake-action@v6
with:
source: .
files: ./docker/docker-compose.build.yaml
targets: ${{ matrix.service_name }}
push: true
set: |
*.tags=${{ env.SEMVER_IMAGE_TAG }}
...🤖 Prompt for AI Agents
In @.github/workflows/production-build.yaml at line 93, The
docker/bake-action@v6 step now defaults to Git context and misses local changes;
update the step that uses docker/bake-action@v6 to add a with: source: .
parameter so the action uses the local path context (keep the existing files,
targets, push, and set entries like *.context=. in the Bake config intact).
Locate the action invocation referencing docker/bake-action@v6 and insert the
source: . under its with: block to restore the v5 behavior.
2 participants
Summary
Upgrade GitHub Actions to their latest versions for improved features, bug fixes, and security updates.
Changes
astral-sh/setup-uvv5v7docker/bake-actionv5v6docker/build-push-actionv5v6slackapi/slack-github-actionv2.1.0v2.1.1stefanzweifel/git-auto-commit-actionv5v7Why upgrade?
Keeping GitHub Actions up to date ensures:
Security Note
Actions that were previously pinned to commit SHAs remain pinned to SHAs (updated to the latest release SHA) to maintain the security benefits of immutable references.
Testing
These changes only affect CI/CD workflow configurations and should not impact application functionality. The workflows should be tested by running them on a branch before merging.