Changed Docker image artifact upload to fork-only#28078
Conversation
Same-org CI runs publish Docker images to GHCR, so downstream jobs can pull from the registry and do not need a saved tarball artifact. Keeping the artifact path only for fork/cross-repo PRs avoids unnecessary docker save and upload work on the common path.
WalkthroughThe PR adds conditional 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #28078 +/- ##
=======================================
Coverage 73.80% 73.81%
=======================================
Files 1528 1528
Lines 129417 129417
Branches 15504 15506 +2
=======================================
+ Hits 95521 95527 +6
- Misses 32917 32934 +17
+ Partials 979 956 -23
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Summary
Expected savings
Based on recent successful same-org CI runs, the production image tarball is saved and uploaded even though downstream jobs pull the image from GHCR:
Expected same-org build-lane saving: about 35-55 seconds in
Build & Publish Artifacts. This can also unblockBuild E2E Docker Imagesooner because that job depends onjob_build_artifacts.Conditions
steps.strategy.outputs.use-artifact == 'false', which is the normal same-org path where images are pushed to GHCR.use-artifact == 'true', which covers external forks and cross-repo PRs that cannot push the image to GHCR.use-artifact=falseand publishes images to GHCR.Testing