Add a dry-run mode to PublishOnPyPI

[pytooling-claude]

New Features

• PublishOnPyPI.yml takes a dry_run input (default 'false'). When enabled, the two twine upload steps
  are replaced by one twine check dist/*.whl dist/*.tar.gz. Everything before them is unchanged, so the artifact
  download, the Python setup and the dependency install still run — and the package metadata is now validated
  rather than merely built.

• CompletePipeline.yml forwards it as pypi_dry_run (default 'false'), so no consumer changes behaviour.

Bug Fixes

• Both verification pipelines failed on every tag. _Checking_SimplePackage_Pipeline.yml and
  _Checking_NamespacePackage_Pipeline.yml each run CompletePipeline.yml over a fixture package, and each died
  at ⤴ Publish Python wheel package to PyPI:

  tag	SimplePackage	NamespacePackage
  v7.14.1	30688872834 ❌	30688872788 ❌
  v7.15.0	30862520158 ❌	30862520222 ❌

  myPackage and myFramework.Extension exist to exercise the job templates; nobody publishes them. On a branch
  push the release jobs are skipped, so this only shows on a tag — which is the run someone checks before cutting
  a release.

  [!IMPORTANT]
  This pull-request adds the switch; a follow-up flips it. Setting pypi_dry_run: 'true' in the two
  verification pipelines cannot be part of this branch: they call CompletePipeline.yml@dev, so an input that
  exists only here makes GitHub reject the workflow file before a runner is assigned — "This run likely failed
  because of a workflow file issue", both pipelines, no job recorded. It was tried on this branch
  (34158873764) and reverted.

  Once this is on dev, the follow-up is one line in each file:

        pypi_dry_run:        'true'   # 'myPackage'/'myFramework' are fixtures - never publish them

Documentation

• PublishOnPyPI.rst and CompletePipeline.rst gain the new parameter in the summary table and a full input
  section. The Behavior list of PublishOnPyPI.rst says that steps 3 and 4 become a twine check.

Others

• Why a dry run rather than skipping the job. The other option was an input that drops PublishOnPyPI from
  the pipeline entirely. That leaves the job template unverified, which is what the verification pipelines exist
  to prevent — the templates are meant to demonstrate the publish path, not only to be green. A dry run keeps the
  job in the graph, keeps its needs: edges meaningful, and still reaches the packages.

  Pointing the fixtures at TestPyPI was the third option. It needs a repository-URL input, a second token
  secret and the two fixture names registered there, and it would upload build artifacts of a package that is not
  a product. It can still be added later on top of this input.

• dry_run is deliberately on PublishOnPyPI.yml rather than only in the verification pipelines: a fork that
  builds a package it must not push under the upstream project's PyPI name needs exactly this switch.

• Adding an input that nothing in this repository sets yet is the price of the @dev reference in the
  verification pipelines. It is the same bootstrap constraint that makes a branch's job-template changes
  untestable by that branch's own CI.

Verification

twine check was run against both fixture packages, built the way Package.yml builds them — python -m build --sdist and python -m build --wheel from the source tree, with build isolation, so the backend resolved
pyTooling ~= 8.17 itself rather than using whatever is installed. twine 7.0.0:

Checking simple/mypackage-7.16.0-py3-none-any.whl: PASSED
Checking simple/mypackage-7.16.0.tar.gz: PASSED
Checking namespace/myframework_extension-7.16.0-py3-none-any.whl: PASSED
Checking namespace/myframework_extension-7.16.0.tar.gz: PASSED

Exit code 0 for both pipelines' packages. twine check --strict, which turns the renderer's warnings into
errors, passes on all four as well — so tightening the dry run to --strict later is available and costs nothing
today.

Known Issues

• NamespacePackage fails on tags for a second, unrelated reason as well — PDFDocumentation — so that
  pipeline stays red until the MiKTeX image gains luatex85.sty. This change removes one of its two failures.

---

Related Issues and Pull-Requests

• Found while confirming that the "PyLint on every push" failure was closed by Fix submodule detection, the CleanupArtifacts NameError and the skippable Bandit scan #246. Not the same defect.
• The same shape of problem is open for PublishToGitHubPages.yml, which cannot be verified at all without
  overwriting this repository's own GitHub Pages site. A dry_run there would let the NamespacePackage pipeline
  cover the pages path; this pull-request does not attempt it.

[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 (1df25ad)	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 (#256)	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 (1df25ad).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #256   +/-   ##
=======================================
  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.