Enhance Docker publish workflow with scheduling#2301
Enhance Docker publish workflow with scheduling#2301NerdsCorp wants to merge 3 commits intopelican-dev:mainfrom
Conversation
Added a scheduled cron job to trigger builds and updated version handling for scheduled events.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdded a weekly scheduled trigger to the Docker publish workflow. Scheduled runs query the Releases API for the latest tag, export Changes
Sequence Diagram(s)sequenceDiagram
participant Scheduler as GitHub Actions (schedule)
participant Runner as Actions Runner
participant Releases as GitHub Releases API
participant Repo as Git Checkout
participant Builder as Docker Build & Push
Scheduler->>Runner: trigger workflow (scheduled)
Runner->>Releases: GET /repos/:owner/:repo/releases/latest
Releases-->>Runner: 200 + release { tag_name }
Runner->>Runner: export version_tag, schedule_tag
Runner->>Repo: checkout ref = schedule_tag (if schedule) else github.ref
Runner->>Runner: update config/app.php (VERSION = version_tag or build_info)
Runner->>Builder: docker build/push (tags: latest?, raw version_tag?) with VERSION
Builder-->>Runner: push result
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/docker-publish.yml (1)
80-123:⚠️ Potential issue | 🔴 CriticalBuild scheduled images from the latest release ref, not
main.Scheduled workflows run on the default branch (main) unless checkout is overridden. Currently, line 80 checks out
main, but lines 117–123 only set a version output variable without actually checking out the release tag. This causes the image to be built from unreleasedmaincode while being stamped with the latest release version. Additionally, if the API returns no releases,jq -r '.tag_name'returns the string "null", and the fallback at lines 148 and 159 usesbuild_info.outputs.version_tag, which isrefs/heads/mainfor scheduled runs.🐛 Proposed fix: fetch, validate, and check out the latest release tag before building
- - name: Code checkout - uses: actions/checkout@v4 + - name: Get latest release tag (scheduled) + id: release_info + if: github.event_name == 'schedule' + env: + GITHUB_TOKEN: ${{ github.token }} + run: | + set -euo pipefail + LATEST_TAG="$(curl -fsSL \ + -H "Authorization: Bearer ${GITHUB_TOKEN}" \ + -H "Accept: application/vnd.github+json" \ + "https://api.github.com/repos/${{ github.repository }}/releases/latest" | jq -er '.tag_name // empty')" + + echo "release_tag=${LATEST_TAG}" >> "$GITHUB_OUTPUT" + echo "version_tag=${LATEST_TAG#v}" >> "$GITHUB_OUTPUT" + + - name: Code checkout + uses: actions/checkout@v4 + with: + ref: ${{ steps.release_info.outputs.release_tag || github.ref }} @@ - # Fetch the latest release tag from GitHub API for use in scheduled builds - - name: Get latest release tag (scheduled) - id: release_info - if: github.event_name == 'schedule' - run: | - LATEST_TAG=$(curl -s https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r '.tag_name') - echo "version_tag=${LATEST_TAG/v/}" >> $GITHUB_OUTPUTAlso applies to: 145–159
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-publish.yml around lines 80 - 123, The scheduled workflow checks out the default branch but never actually checks out the latest release tag produced by the "Get latest release tag (scheduled)" step, causing images to be built from main while stamped with a release version and allowing "null" tag values; fix by making the "Code checkout" or a following step use the release_info output ref when github.event_name == 'schedule' (e.g., pass ref=${{ steps.release_info.outputs.version_tag }} into actions/checkout or run git fetch && git checkout "$LATEST_TAG"), validate the API result in the "Get latest release tag (scheduled)" step to ensure LATEST_TAG is not empty or "null" before exporting it (and fall back to build_info.outputs.version_tag only if validation fails), and ensure subsequent steps use the release_info.outputs.version_tag (or the validated fallback) for image tagging and builds.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/docker-publish.yml:
- Around line 160-161: The scheduled build is using steps.release_info to fetch
the release tag but never applies it to the image tags; update the workflow's
tags field so it includes the release tag (steps.release_info.outputs.tag) in
addition to steps.docker_meta.outputs.tags for the scheduled path. In practice,
modify the tags entry (the tags field that currently references
steps.docker_meta.outputs.tags) to append the release tag when present (guarding
against empty values) so scheduled builds push an image tagged with the release;
locate the tags setting alongside labels and ensure you reference
steps.release_info and steps.docker_meta.outputs.tags in the combined
expression.
---
Outside diff comments:
In @.github/workflows/docker-publish.yml:
- Around line 80-123: The scheduled workflow checks out the default branch but
never actually checks out the latest release tag produced by the "Get latest
release tag (scheduled)" step, causing images to be built from main while
stamped with a release version and allowing "null" tag values; fix by making the
"Code checkout" or a following step use the release_info output ref when
github.event_name == 'schedule' (e.g., pass ref=${{
steps.release_info.outputs.version_tag }} into actions/checkout or run git fetch
&& git checkout "$LATEST_TAG"), validate the API result in the "Get latest
release tag (scheduled)" step to ensure LATEST_TAG is not empty or "null" before
exporting it (and fall back to build_info.outputs.version_tag only if validation
fails), and ensure subsequent steps use the release_info.outputs.version_tag (or
the validated fallback) for image tagging and builds.
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 3fa85f8c-eb6a-4fe1-a3c0-86f68f2604fa
📒 Files selected for processing (1)
.github/workflows/docker-publish.yml
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
.github/workflows/docker-publish.yml (1)
98-108:⚠️ Potential issue | 🟠 MajorScheduled builds will push an image with no release tag.
docker_metaonly emits tags forrelease+published(the rawlatest), tag refs, or branch refs. On ascheduleevent,github.refisrefs/heads/main(the checkoutref:override does not change whatmetadata-actionsees), so none of the threetags:rules fire andsteps.docker_meta.outputs.tagsis empty. TheBuild and Push (tag)step then pushes an image with no image tag, which defeats the purpose of the weekly rebuild — users pulling:latestor:<version>will not receive the refreshed image.Add explicit tags for the schedule path (or extend the metadata tag rules to cover
github.event_name == 'schedule'usingsteps.release_info.outputs.version_tag), e.g.:Proposed fix
tags: | type=raw,value=latest,enable=${{ (github.event_name == 'release' && github.event.action == 'published' && github.event.release.prerelease == false) || github.event_name == 'schedule' }} + type=raw,value=${{ steps.release_info.outputs.version_tag }},enable=${{ github.event_name == 'schedule' }} type=ref,event=tag type=ref,event=branchNote
metadata-actionruns beforerelease_infoin the current ordering — you'll need to move therelease_infostep aboveDocker metadatafor the output to be available.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-publish.yml around lines 98 - 108, The Docker metadata step (docker_meta) emits no tags for schedule events so steps.docker_meta.outputs.tags is empty and the scheduled build pushes an untagged image; fix by updating the docker/metadata-action tag rules to include schedule events (e.g. add a tags rule with condition github.event_name == 'schedule' using the version from steps.release_info.outputs.version_tag or a raw latest tag for schedule) and ensure release_info runs before docker_meta so steps.release_info.outputs.version_tag is available (adjust step ordering around release_info and the "Build and Push (tag)" step accordingly).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/docker-publish.yml:
- Around line 152-156: The sed replacement is using a fragile fallback
(steps.release_info.outputs.version_tag || steps.build_info.outputs.version_tag)
which can inject raw GITHUB_REF like refs/heads/main into config/app.php; update
the job to validate/branch before running sed: explicitly check
github.event_name (e.g., run different commands for 'release' vs 'schedule') or
assert that at least one of steps.release_info.outputs.version_tag or
steps.build_info.outputs.version_tag is non-empty and valid (fail-fast if not)
and only then perform the sed that replaces 'version' => 'canary' with the
validated version_tag; locate the sed invocation and the release_info/build_info
step names to implement this guard.
- Around line 84-91: The current release-tag fetch using LATEST_TAG=$(curl -s
https://api.github.com/repos/${{ github.repository }}/releases/latest | jq -r
'.tag_name') is brittle: make the curl call authenticated and fail on non-2xx
responses by passing the GITHUB_TOKEN in an Authorization header and checking
the HTTP status (so the step errors instead of parsing an error body), keep
using jq only after a successful response, and replace the substring removal
${LATEST_TAG/v/} with the prefix-only expansion ${LATEST_TAG#v} to strip only a
leading "v" when writing version_tag and schedule_tag outputs.
---
Duplicate comments:
In @.github/workflows/docker-publish.yml:
- Around line 98-108: The Docker metadata step (docker_meta) emits no tags for
schedule events so steps.docker_meta.outputs.tags is empty and the scheduled
build pushes an untagged image; fix by updating the docker/metadata-action tag
rules to include schedule events (e.g. add a tags rule with condition
github.event_name == 'schedule' using the version from
steps.release_info.outputs.version_tag or a raw latest tag for schedule) and
ensure release_info runs before docker_meta so
steps.release_info.outputs.version_tag is available (adjust step ordering around
release_info and the "Build and Push (tag)" step accordingly).
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 724306aa-f325-4ba5-b0c5-0e56b295681a
📒 Files selected for processing (1)
.github/workflows/docker-publish.yml
Updated Docker publish workflow to improve tag fetching and version handling and hopefully make rabbit happy.
|
@coderabbitai recheck |
|
✅ Actions performedReview triggered.
|
Added a weekly scheduled build that runs every Monday at midnight UTC. It rebuilds and repushes the latest release tag so the Docker image stays fresh with up to date base images and dependencies, without needing a new release to trigger it.
This will close #2300