Let a tag publish to GitHub Pages again

[pytooling-claude]

Bug Fixes

• CompletePipeline.yml stopped publishing GitHub Pages on tag runs. CompletePipeline: publish Pages only from branches the environment admits #249 guarded
  PublishToGitHubPages on the ref, because the github-pages environment rejects a deployment from a feature
  branch before a runner is assigned — one second, no steps, no log — so every feature-branch pipeline showed a
  red job unrelated to its own changes. That part was right.

  The guard was written as an allowlist of the two refs that had been observed to deploy:

  && (github.ref_name == github.event.repository.default_branch || github.ref_name == 'dev')

  On a tag push github.ref_name is the tag, so the job is skipped — not failed, skipped, which is why
  nothing reports it. And a tag run is exactly the run whose documentation matters most.

  Tags are admitted by the environment. pyVHDLModel's v0.39.0 pipeline, still on @r7, deployed Pages from
  ref_name = v0.39.0 — run 30951229155, job
  PublishToGitHubPages / 📖 Merge multiple contents for publishing → success.

  The fix adds one term:

  && (github.ref_type == 'tag'
   || github.ref_name == github.event.repository.default_branch
   || github.ref_name == 'dev')

  Feature branches stay blocked, which is what the guard was for.

Documentation

• CompletePipeline.rst states, where documentation_steps is described, that pages additionally depends on
  the ref being one the environment admits — a tag, the default branch, or dev — and why the job is skipped
  rather than failing on any other branch.

• doc/Development.rst, Conditional Jobs → Guidelines, gains the rule this came from: a condition gating a
  job on the ref is a blocklist of the refs that cannot work, never an allowlist of the refs that have been seen
  to work. Observing one rejection says nothing about which other refs are admitted, so an allowlist built from
  that observation silently drops every ref that was simply never tried — and drops it by skipping, which no
  pipeline reports. CompletePipeline: publish Pages only from branches the environment admits #249 is written up there as the worked example.

Known Issues

• Whether every consumer's github-pages environment admits tags is not knowable from here. pyVHDLModel's
  does. A repository configured with Selected branches only would see the pre-CompletePipeline: publish Pages only from branches the environment admits #249 failure again on tag runs —
  which was the status quo before CompletePipeline: publish Pages only from branches the environment admits #249, and is at least loud rather than silent. If that is not acceptable, the
  guard has to become an input (pages_refs or similar) rather than a fixed expression, because the answer is
  per-repository configuration that a job template cannot see. This pull-request takes the simpler option.

• The verification pipelines cannot catch this class of defect. Neither _Checking_SimplePackage_Pipeline.yml
  nor _Checking_NamespacePackage_Pipeline.yml passes pages in documentation_steps, because deploying would
  overwrite this repository's own site. So the original guard shipped, was reviewed and was written up in release
  notes with no automated check able to contradict it. That is the second concrete cost of the missing dry_run
  on PublishToGitHubPages.yml.

Others

• Nothing is broken today. CompletePipeline: publish Pages only from branches the environment admits #249 exists only on dev, main and r8, and all eleven repositories calling
  CompletePipeline.yml are still on @r7. The defect fires on the first migration — and since
  documentation_steps defaults to 'html pages', it fires for all eleven.

• This wants a v8.0.1 patch release. Unlike the major, a patch moves r8, so consumers pick it up without
  editing anything.

---

Related Issues and Pull-Requests

• Fixes a regression introduced by CompletePipeline: publish Pages only from branches the environment admits #249 and released in v8.0.0 (v8.0.0 #248).
• Found while checking the v8.0.0 tag pipelines — by looking at which jobs did not run, rather than which failed.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage ∅ diff coverage · +0.00% coverage variation

Metric	Results
Coverage variation	✅ +0.00% coverage variation
Diff coverage	✅ ∅ diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (8e631fc)	45	41	91.11%
Head commit (569f3ae)	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 (#259)	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%

_{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]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.22%. Comparing base (8e631fc) to head (569f3ae).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #259   +/-   ##
=======================================
  Coverage   82.22%   82.22%           
=======================================
  Files           1        1           
  Lines          45       45           
  Branches        9        9           
=======================================
  Hits           37       37           
  Misses          4        4           
  Partials        4        4           

Flag	Coverage Δ
unittests	82.22% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.