Fix Pages artifact selection when rerunning deployments - #3
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe GitHub Pages deployment workflow now assigns a run-attempt-specific artifact name during upload and passes the same name to the deployment action. ChangesPages deployment
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The workflow change is consistent with the documented Pages artifact inputs and is mergeable. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Git: CodeRabbit could not clone the repository, so clone-backed analysis was skipped and this review may be incomplete. Verify repository clone access, such as SSH credentials, before requesting another full review. If clone access is intentionally unavailable, use Comment |
Rebuilding after configuring rlalign.ai succeeded, but publishing failed because a rerun retained two artifacts named
github-pagesin the same workflow run.Give each attempt its own artifact name using
github.run_attempt, and pass that same name to the deployment action. This lets the publisher select the newly built site when a deployment is retried.Validation: the root-domain build and all 16 local resource checks passed before the artifact selection failure. The upload and deployment inputs were checked against the official actions. The existing CI checks both root and project-path builds; deployment will verify the updated artifact selection.
Summary by CodeRabbit