CompletePipeline: publish Pages only from branches the environment admits - #249
CompletePipeline: publish Pages only from branches the environment admits#249pytooling-s-claude-bot[bot] wants to merge 1 commit into
Conversation
…mits The 'github-pages' environment admits the default branch and 'dev' only, so the deploy job on any other branch is failed by GitHub before a runner is assigned - one second, no steps, no log. Every feature-branch pipeline therefore shows a red job that has nothing to do with its changes, which is how a real failure gets overlooked. pyTooling fixed this in its own pipeline (pyTooling#297) by guarding the job. Repositories calling 'CompletePipeline.yml' cannot do that - they have no per-job 'if:' to add - so the guard belongs here, where it reaches every consumer at once. Co-Authored-By: Patrick Lehmann <Paebbels@gmail.com>
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Coverage variation | ✅ +0.00% coverage variation |
| Diff coverage | ✅ ∅ diff coverage |
Coverage variation details
Coverable lines Covered lines Coverage Common ancestor commit (3304003) Report Missing Report Missing Report Missing Head commit (7afa58c) 45 (+0) 41 (+0) 91.11% (+0.00%) Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch:
<coverage of head commit> - <coverage of common ancestor commit>
Diff coverage details
Coverable lines Covered lines Diff coverage Pull request (#249) 0 0 ∅ (not applicable) Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified:
<covered lines added or modified>/<coverable lines added or modified> * 100%
1 Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #249 +/- ##
=======================================
Coverage 82.22% 82.22%
=======================================
Files 1 1
Lines 45 45
Branches 9 9
=======================================
Hits 37 37
Misses 4 4
Partials 4 4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Bug Fixes
CompletePipeline.ymlpublishes to GitHub Pages only from branches thegithub-pagesenvironment actuallyadmits - the repository's default branch and
dev.The environment's protection rules reject a deployment from any other branch before a runner is assigned:
the job fails after one second, with no step recorded, and the annotation reads
So every feature-branch pipeline shows a red job that has nothing to do with its changes. That is how a real
failure gets overlooked.
pyTooling fixed this in its own pipeline (pyTooling#297) with
a per-job
if:. Repositories that callCompletePipeline.ymlcannot do the same - they hand over the wholepipeline and have no job to guard - so the condition belongs here, where it reaches every consumer at once.
Others
CompletePipeline.yml, so it wants a release ofActionsbefore consumers see it, and a deliberate look at any repository that publishes Pages from a branchother than its default or
dev- the guard would stop that. I know of none in this workspace.The condition is written against
github.event.repository.default_branchrather than a hard-codedmain, sorepositories on
masterare covered too.Related Issues and Pull-Requests
PublishToGitHubPages; pyGHDL carriesthe same symptom.