Fix: Fix of Docker Image Version Release#434
Conversation
|
@gowthamkishore3799 is attempting to deploy a commit to the Inbox Zero Team on Vercel. A member of the Team first needs to authorize it. |
|
github-actions seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
|
""" WalkthroughThe GitHub Actions workflow for building and publishing Docker images was refactored. Job Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub Actions
participant Repo
participant DockerHub
GitHub Actions->>Repo: Fetch latest main branch (fetch-version)
GitHub Actions->>Repo: Read version.txt
GitHub Actions->>Repo: Bump version and prepare update (update_version_txt)
GitHub Actions->>Repo: Commit and push updated version.txt
GitHub Actions->>DockerHub: Build and push Docker image tagged with new version (build-docker)
Possibly related PRs
Poem
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (2)
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. 🪧 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 (
|
|
Have signed the CLA |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
.github/workflows/build_and_publish_docker.yml (5)
30-34: Add explicit pull of latest code before version read
Fetching and pulling themainbranch ensures you always operate on the up-to-date codebase. Alternatively, you could setfetch-depth: 0andfetch-tags: truein the initial checkout to achieve a similar outcome.
54-66: Validate base version format before bump
While the patch-increment logic correctly reads and bumps the version segments, consider adding a sanity check to ensureBASE_VERSIONmatches a semantic version pattern (e.g.,^v?\d+\.\d+\.\d+$) to avoid script failures on malformed input.
84-84: Reconsiderforce: truepush behavior
Using a force push can overwrite remote changes unexpectedly. For safer operation, preferforce_with_lease: trueto ensure you don’t clobber concurrent commits.
108-110: Updatedocker/setup-buildx-actionto latest major version
docker/setup-buildx-action@v2may lack recent features or compatibility fixes. Consider upgrading to the latest major release (for example,@v3).- uses: docker/setup-buildx-action@v2 + uses: docker/setup-buildx-action@v3🧰 Tools
🪛 actionlint (1.7.4)
109-109: the runner of "docker/setup-buildx-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
111-112: Updatedocker/build-push-actionto latest major version
To leverage the newest improvements and ensure compatibility, bump to the latest release (e.g.,@v5).- uses: docker/build-push-action@v4 + uses: docker/build-push-action@v5🧰 Tools
🪛 actionlint (1.7.4)
112-112: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/build_and_publish_docker.yml(3 hunks)version.txt(1 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/build_and_publish_docker.yml
109-109: the runner of "docker/setup-buildx-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
112-112: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🔇 Additional comments (5)
version.txt (1)
1-2: Ensure newline at end of file
Adding a trailing newline prevents potential parsing issues when reading the version string in CI..github/workflows/build_and_publish_docker.yml (4)
19-25: Renameset-versionjob tofetch-versionwith proper outputs
The new job name accurately reflects its purpose of fetching the version, and the output mapping fromsteps.set_version.outputs.versionis correctly configured.
43-45: Simplify dependencies for version update
Theupdate_version_txtjob now only depends onfetch-version, reducing unnecessary coupling with the Docker build. This streamlines the workflow.
71-77: Review Git tag placement and version strategy
The workflow tags the previous version (needs.fetch-version.outputs.version) before committing the bump. Please verify that this aligns with your release strategy. If you intend to tag the newly bumped version instead, adjust the tag command to usesteps.update_version.outputs.new_version.
87-94: Confirm build context and checkout revision
Thebuild-dockerjob depends on the version update, but the checkout step defaults to the commit that triggered the workflow, not the bumped version commit. If you need the bumpedversion.txtin the build context, specify:with: ref: main fetch-depth: 0in the checkout action.
|
Thanks for this! I made an adjustment earlier to improve security so there's a merge conflict. This was the PR I added: #435 |
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
.github/workflows/build_and_publish_docker.yml (1)
71-79:⚠️ Potential issueFix broken job output reference
TheVERSIONenvironment variable is still referencingneeds.set-version.outputs.version(old job name), which no longer exists. This will break the commit and tag steps.Please update to reference the
fetch-versionjob:- VERSION: ${{ needs.set-version.outputs.version }} + VERSION: ${{ needs.fetch-version.outputs.version }}Additionally, ensure the
git tagcommand uses this updatedVERSION.🧰 Tools
🪛 actionlint (1.7.4)
71-71: property "set-version" is not defined in object type {fetch-version: {outputs: {version: string}; result: string}}
(expression)
🧹 Nitpick comments (2)
.github/workflows/build_and_publish_docker.yml (2)
114-115: Bumpbuild-push-actionto latest
Consider upgradingdocker/build-push-action@v4to@v5(or the latest release) to leverage new features and ensure long-term support.🧰 Tools
🪛 actionlint (1.7.4)
114-114: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
123-125: Validate tagging logic
You're tagging the image with${{ needs.fetch-version.outputs.version }}(the pre-bump version) andlatest. Confirm that you intend to publish the previous version (pre-bump) rather than the newly bumped version. If you want to release the new version, switch this to useneeds.update_version.outputs.new_version.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build_and_publish_docker.yml(5 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/build_and_publish_docker.yml
111-111: the runner of "docker/setup-buildx-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
114-114: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🔇 Additional comments (5)
.github/workflows/build_and_publish_docker.yml (5)
30-34: Ensure latest code is fetched before version reading
The new Force Pull Latest Code step correctly ensures that themainbranch is up-to-date before readingversion.txt. This addresses timing issues where outdated code could lead to incorrect version tags.
44-45: Simplify job dependency
Updatingupdate_version_txtto depend only onfetch-version(instead of the oldbuild-docker) streamlines the control flow and ensures the version bump runs immediately after fetching the latest version.
59-66: Consistent job output reference
You’re correctly usingneeds.fetch-version.outputs.versionto seed the bump logic. This replaces the oldset-versionjob reference and aligns the variable naming.
86-87: Confirm forced push semantics
Switching fromforce_with_leasetoforce: truemay overwrite concurrent changes unexpectedly. Consider whether a saferforce_with_lease: truebetter fits your branch protection rules.
111-112: Update outdated Buildx action version
Thedocker/setup-buildx-action@v2might be superseded by@v3. Please verify the latest stable version and update accordingly to avoid compatibility issues.🧰 Tools
🪛 actionlint (1.7.4)
111-111: the runner of "docker/setup-buildx-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
.github/workflows/build_and_publish_docker.yml (1)
74-78:⚠️ Potential issueCritical: Tagging old version instead of the new one.
You're currently tagging the bumped commit with the previous$VERSION. To correctly mark the release, update the tag command to useNEW_VERSION:- git tag -a "$VERSION" -m "Release version $VERSION" + git tag -a "$NEW_VERSION" -m "Release version $NEW_VERSION"This ensures your Git tag reflects the file content after the bump.
♻️ Duplicate comments (1)
.github/workflows/build_and_publish_docker.yml (1)
98-102: Ensurebuild-dockerchecks out the bumpedmain.
By default,actions/checkoutin this job will pull the workflow-triggering commit (pre-bump). You need to fetch the branch head after the bump:- - name: Checkout code - uses: actions/checkout@v4 - with: - fetch-depth: 0 + - name: Checkout code + uses: actions/checkout@v4 + with: + ref: main + fetch-depth: 0This matches the earlier recommendation.
🧹 Nitpick comments (2)
.github/workflows/build_and_publish_docker.yml (2)
30-34: Replace manual git fetch/pull withactions/checkoutfor clarity and efficiency.
Instead of fetching and pulling via shell, directly check out the latestmainwith full history:- - name: Force Pull Latest Code - run: | - git fetch origin main - git pull origin main + - name: Checkout latest main branch + uses: actions/checkout@v4 + with: + ref: main + fetch-depth: 0This reduces complexity and avoids merge conflicts.
86-86: Useforce_with_leaseinstead offorcefor safer pushes.
force_with_lease: trueprevents you from overwriting upstream changes unintentionally:- force: true + force_with_lease: true
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build_and_publish_docker.yml(4 hunks)
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/build_and_publish_docker.yml
111-111: the runner of "docker/setup-buildx-action@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
114-114: the runner of "docker/build-push-action@v4" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🔇 Additional comments (2)
.github/workflows/build_and_publish_docker.yml (2)
44-44: Updated dependency order looks good.
Changingupdate_version_txtto depend only onfetch-versionensures the version bump runs before the Docker build, matching the PR objective.
59-59: Version bump logic is solid.
The script correctly parsesversion.txt, defaults missing components, and increments the patch number.
|
Still seems to be failing :( not sure if this is because something got lost in the merges? Did you check it was working beforehand? |
|
Hi @elie222, We are currently facing a race condition issue, and I need your input to debug further. When merging PRs, do you typically merge them almost simultaneously (within a minute of each other) or go through them one by one? If they are merged almost simultaneously, we may need to avoid concurrent Docker image builds to prevent conflicts. Your insights would help us narrow down the cause. |
|
Coz of which the version.txt didnt get updated |
Hey, usually we don't have multiple merged at one time. Sometimes I push to main though if that impacts things. |
|
ack, pushing to main shouldnt affect it, let me check that unless a race condition is faced , ill check in deep |
3 participants
Currently, the next build process takes time, requiring the build to complete before updating the tags. This delay is causing multiple image builds to fail. The issue is resolved by updating the version first and then building the image.
Refactor
Chores
Summary by CodeRabbit