Repository navigation
ci(deploy): wait for docker-publish before firing homelab webhook - #437
Conversation
Deploy and docker-publish both trigger on push to main, causing a race condition where deploy.sh pulls stale 'latest' images. Add a polling step that waits up to 10min for docker-publish to complete before firing the homelab webhook. Skips the wait when no Docker changes are present in the push.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization 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)
📝 WalkthroughWalkthroughAdds a workflow step to the deploy GitHub Actions workflow that locates the most recent Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant DeployWF as Deploy Workflow
participant GHCLI as GH CLI (gh)
participant ActionsAPI as GitHub Actions API
participant DockerPublish as docker-publish run
DeployWF->>GHCLI: gh run list (filter by workflow docker-publish & headSha)
GHCLI->>ActionsAPI: request runs list
ActionsAPI-->>GHCLI: returns runs metadata
alt no matching run within initial window
GHCLI-->>DeployWF: no run found -> exit success (proceed deploy)
else matching run found
GHCLI->>ActionsAPI: gh run view <run-id> (poll until status=completed or timeout)
loop polling (up to max_wait)
ActionsAPI-->>GHCLI: status / conclusion updates
end
alt conclusion == success
GHCLI-->>DeployWF: success -> allow deploy
else conclusion != success or timeout
GHCLI-->>DeployWF: fail -> abort deploy
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/deploy.yml (1)
34-35: Harden GH CLI for stream-friendly logsSet
GH_PAGER=cat(or equivalent) to guarantee non-paged CLI output in CI logs.As per coding guidelines, "Ensure logs are stream-friendly (no pagers) in scripts; when a pager might be used, pipe to cat".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 34 - 35, The workflow run step currently sets the shell flags with "set -euo pipefail" but does not enforce non-paged GH CLI output; update the same run block (the step containing the "set -euo pipefail" line) to set GH_PAGER=cat for the environment used by the GH CLI so logs are stream-friendly—e.g., export or prefix GH_PAGER=cat before invoking gh commands in that run step (ensure the change is applied in the run block that contains "set -euo pipefail").
🤖 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/deploy.yml:
- Around line 32-34: The deploy workflow fails under hardened repo permissions
because the "Wait for Docker images" step uses the GitHub CLI commands (gh run
list / gh run view) but the GITHUB_TOKEN (GH_TOKEN) lacks actions:read scope;
update the workflow to grant actions: read to the job or workflow by adding a
permissions block that includes actions: read so the GH_TOKEN used in the "Wait
for Docker images" step can call gh run list and gh run view without 403 errors.
- Around line 52-55: The workflow currently exits immediately when run_info is
empty, causing a race; modify the block that checks run_info (the result of the
`gh run list` query for the `docker-publish` workflow) to poll up to 60 seconds
(e.g., 12 attempts with 5s sleeps) re-running the `gh run list` check each
attempt and breaking early if a `docker-publish` run appears; if after the
timeout no run is found then proceed with the existing exit 0 branch. Use the
existing variable name run_info and the same `gh run list` query for detection,
and ensure the loop has a bounded retry count so it never blocks indefinitely.
---
Nitpick comments:
In @.github/workflows/deploy.yml:
- Around line 34-35: The workflow run step currently sets the shell flags with
"set -euo pipefail" but does not enforce non-paged GH CLI output; update the
same run block (the step containing the "set -euo pipefail" line) to set
GH_PAGER=cat for the environment used by the GH CLI so logs are
stream-friendly—e.g., export or prefix GH_PAGER=cat before invoking gh commands
in that run step (ensure the change is applied in the run block that contains
"set -euo pipefail").
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 97c6cfa1-c0a1-4311-8bef-610edcc91abd
📒 Files selected for processing (1)
.github/workflows/deploy.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: SonarCloud Scan
- GitHub Check: Quality Gates
🧰 Additional context used
📓 Path-based instructions (7)
**/{.github/workflows,}/*.{yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/ci-cd.mdc)
**/{.github/workflows,}/*.{yml,yaml}: CI pipeline must include setup step (node install, environment)
CI pipeline must include lint step (TypeScript typecheck + linter)
CI pipeline must include build step (production build)
CI pipeline must include test step (unit + integration) with coverage report
CI pipeline must include quality step (static analysis, vulnerability scan)
Files:
.github/workflows/deploy.yml
**/{.github/workflows,dependabot.yml}/*.{yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/ci-cd.mdc)
Configure dependency update bot with PR templates and tests (recommended)
Files:
.github/workflows/deploy.yml
**/.github/workflows/*.{yml,yaml}
📄 CodeRabbit inference engine (.cursor/rules/ci-cd.mdc)
**/.github/workflows/*.{yml,yaml}: Configure SAST / secrets scan on PRs (recommended)
Publish artifacts only from protected pipeline steps
Files:
.github/workflows/deploy.yml
{jest.config.*,*.coverage.*,.nycrc*,nyc.config.*,coveragerc,.github/workflows/*.yml,.github/workflows/*.yaml}
📄 CodeRabbit inference engine (.cursor/rules/testing-quality.mdc)
Minimum recommended coverage threshold: 85% (raise per project risk)
Files:
.github/workflows/deploy.yml
{.github/workflows/*.{yml,yaml},*.github/workflows/*.{yml,yaml},.gitlab-ci.yml,.circleci/config.yml,bitbucket-pipelines.yml}
📄 CodeRabbit inference engine (.cursor/rules/testing-quality.mdc)
CI must run in order: lint → build → test → quality checks
Files:
.github/workflows/deploy.yml
{.github/workflows/**/*.{yml,yaml},**/.gitlab-ci.yml,.circleci/config.yml}
📄 CodeRabbit inference engine (.cursor/rules/workflow.mdc)
{.github/workflows/**/*.{yml,yaml},**/.gitlab-ci.yml,.circleci/config.yml}: CI/CD pipeline must include in order: Setup (Node install, env config) → Lint (TypeScript typecheck, linter) → Build (production build, artifacts) → Test (unit, integration, coverage) → Quality (static analysis, vulnerability scan)
Publish artifacts only from protected pipeline steps in CI/CD
Files:
.github/workflows/deploy.yml
{**/scripts/**,scripts/**,.github/workflows/**/*.{yml,yaml},**/.gitlab-ci.yml,.circleci/config.yml}
📄 CodeRabbit inference engine (.cursor/rules/workflow.mdc)
{**/scripts/**,scripts/**,.github/workflows/**/*.{yml,yaml},**/.gitlab-ci.yml,.circleci/config.yml}: Use cross-platform environment handling in scripts, cross-platform deletion utilities instead of OS-specific commands, pass non-interactive flags (--yes, --ci) by default in automation, and avoid OS-specific commands
Ensure logs are stream-friendly (no pagers) in scripts; when a pager might be used, pipe to cat
Files:
.github/workflows/deploy.yml
|
* ci(deploy): wait for docker-publish before firing webhook Deploy and docker-publish both trigger on push to main, causing a race condition where deploy.sh pulls stale 'latest' images. Add a polling step that waits up to 10min for docker-publish to complete before firing the homelab webhook. Skips the wait when no Docker changes are present in the push. * ci(deploy): fix permissions, pager, and detect polling



Problem
deploy.ymlanddocker-publish.ymlboth trigger onpushto main and run in parallel. The deploy job fires the homelab webhook ~4 seconds after the push, while Docker images take 2–6 minutes to build.deploy.shthen runsdocker pull latestand gets stale images — homelab never receives the new code.Timeline from the last push:
Fix
Add a "Wait for Docker images" step in
deploy.yml(before the webhook trigger) that:docker-publish.ymlis running for the same commit SHA via the GitHub APIBehavior
latesttagsworkflow_dispatch: no docker-publish run for that SHA → fires immediatelySummary by CodeRabbit