v8.0.0

[Paebbels]

New Features

• Two composite actions carry logic that both testing job templates used to hold a copy of (Extract the pip to pacboy translation into two composite actions #253):

  • .github/actions/ComputeRequirements — resolves a ./-prefixed requirements file against a base directory
    and checks that it exists. Inputs requirements, mingw_requirements, base_directory; outputs
    requirements and mingw_requirements.
  • .github/actions/ComputePacboyPackages — holds the pip → MSYS2 rewrite table and translates a requirements
    file (following nested -r) or a dependency list into pacboy packages. Input requirements, output
    pacboy_packages.

  base_directory is a single joined path rather than the three directory inputs, so the action does not need to
  know whether it is called from UnitTesting.yml (root/tests/unit), ApplicationTesting.yml
  (root/tests/app) or StaticTypeCheck.yml (root/tests/typing).

• StaticTypeCheck.yml takes root_directory, tests_directory and typing_directory — defaults '.',
  'tests' and 'typing' — and accepts the ./ requirements syntax through the same action. It had no
  directory parameters at all, which is why its requirements default had to spell the path out. All three
  testing and checking templates now address their requirements files the same way. (Give StaticTypeCheck directory inputs and the './' requirements syntax #257)

Breaking Changes

• ⚠️ A ./-prefixed mingw_requirements addresses a different file. It was passed to pip install
  unprocessed, so ./requirements.txt resolved against the working directory; it now resolves against
  root_directory/tests_directory/unittest_directory (or apptest_directory), exactly like requirements.
  A caller that spelled the path out (-r tests/unit/mingw.txt) is unaffected — only the ./ form changes.
  (Extract the pip to pacboy translation into two composite actions #253)

  This is limited to callers that set mingw_requirements; its default is '', and no pipeline in this
  workspace sets it — CompletePipeline.yml does not even expose the parameter, so the eleven repositories that
  go through it cannot reach this change at all.

Changes

• The pip → pacboy rewrite table is maintained once. UnitTesting.yml and ApplicationTesting.yml each
  carried their own copy of the table, the subPackages table and the ~40-line reader — about 130 lines apiece.
  Both now call the actions. The table had drifted twice, and neither drift was found by a test. (Extract the pip to pacboy translation into two composite actions #253)

• The table is also complete now, and one entry changed meaning. Every entry was recomputed by resolving each
  distribution's requirements transitively down to the distributions that need an MSYS2 package. (Extract the pip to pacboy translation into two composite actions #253)

  • Added: pyEDAA.IPXACT, pyEDAA.OSVVM, pyEDAA.OutputFilter, pyEDAA.ToolSetup, pyEDAA.UCIS,
    pyEDAA.Workflow, pyVersioning, and pyTooling[sphinx].
  • sphinx_reports was incomplete — it listed three of the seven packages it needs. It requires
    pyEDAA.Reports, Coverage and docstr_coverage, so it also needs python-coverage:p, python-lxml:p,
    python-ruamel-yaml:p and python-ruamel.yaml.clib:p. Reachable today: pyEDAA.OSVVM requires
    sphinx_reports.
  • pyEDAA.ProjectModel loses its base entry and moves to subPackages under an osvvm key. Its
    requirements are pyTooling, pyVHDLModel, pySVModel and pySystemRDLModel, none of which has compiled
    code, so the ruamel-yaml/clib/lxml it listed is needed by nothing it pulls in. Only
    pyEDAA.ProjectModel[osvvm] needs anything. This is the only entry that installs fewer packages than
    before.
  • pyTooling's packaging, terminal and testing extras get no entry on purpose — setuptools, colorama and
    pytest are pure Python — and a comment says so.

• ⚠️ StaticTypeCheck.yml's requirements default changes from '-r tests/typing/requirements.txt' to
  '-r ./requirements.txt'. With the directory defaults it resolves to the same file, so a caller that does not
  set the parameter sees no difference, and a caller passing a path without ./ is unaffected too. The one case
  that changes is a caller already passing a ./-prefixed path: it is now rebased onto the typing directory
  instead of the working directory. No consumer does — the two repositories that set the parameter both pass
  -r tests/requirements.txt, and CompletePipeline.yml does not forward it at all. (Give StaticTypeCheck directory inputs and the './' requirements syntax #257)

• StaticTypeCheck.yml runs mypy in root_directory, mirroring how UnitTesting.yml runs pytest. At the
  default '.' this changes nothing. The documentation states what UnitTesting.rst leaves implicit: the report
  paths are written relative to that directory but uploaded relative to the repository root, so a non-default
  value has to be accounted for in both. (Give StaticTypeCheck directory inputs and the './' requirements syntax #257)

• Both testing job templates install ruamel.yaml with its C library on MSYS2. They disagreed:
  UnitTesting.yml installed python-ruamel-yaml alone and kept the clib variant beside it as a comment,
  ApplicationTesting.yml installed both. ruamel.yaml imports _ruamel_yaml from ruamel.yaml.clib and
  silently falls back to its pure-Python parser when that fails; measured on a 186-line file, the C parser is
  6.7× faster (7.63 ms → 1.14 ms). MSYS2 ships python-ruamel.yaml.clib prebuilt, so it costs a download and
  no compilation. (Install 'jsonschema' from pacman on MSYS2 and unify both pacboy tables #252)

• A missing mingw_requirements file is reported before the install rather than during it. The existence
  check that requirements has always had applies to mingw_requirements too, so a typo aborts with a
  FileNotFoundError annotation naming the resolved path. This is not a behaviour change: pip already exited 1
  on a missing requirements file (ERROR: Could not open requirements file), so such a job failed before too —
  just less legibly, and deeper in the log. (Extract the pip to pacboy translation into two composite actions #253)

• The MSYS2 install step of both testing templates lost its if. ComputeRequirements emits the plain
  requirements as its mingw_requirements output when no override is given, so the "override or fall back"
  decision is made once inside the action. (Extract the pip to pacboy translation into two composite actions #253)

• The computed pacboy list is sorted, so the same job produces the same line on two runs and logs can be
  diffed. (Extract the pip to pacboy translation into two composite actions #253)

• InstallPackage.yml keeps its hand-written pacboy: list — it installs the package under test and has no
  requirements file to translate — and carries a comment naming the single source to keep it in sync with. (Extract the pip to pacboy translation into two composite actions #253)

• The shell variable holding a merge commit's second parent is SECOND_PARENT_SHA instead of FATHER_SHA, in
  PrepareJob.yml (10 uses) and PublishReleaseNotes.yml (4 uses). "Second parent" is git's own term and the one
  the step is named after; "father" is not git terminology. GHDL's integrated copy of this logic already used that
  name, so the two now agree.

Bug Fixes

• A job could download an artifact its producer never uploaded. A status check function tolerates a skipped
  dependency — that is what it is for — but it cannot distinguish a dependency that is unrelated from one that
  produces the artifact the job is about to download. Such a job started anyway and failed at the download:

  Unable to download artifact(s): Artifact not found for name: documentation-HTML
  

  Observed on GHDL's pipeline: GitHub cancelled three Windows packaging jobs, the cascade skipped the
  documentation job, and the publishing job ran regardless.

  Three jobs in CompletePipeline.yml now require the job producing each artifact to have succeeded:

  • PDFDocumentation requires Documentation, whose LaTeX sources it converts.
  • PublishToGitHubPages requires Documentation, PublishCoverageResults and StaticTypeCheck — the three
    HTML trees it assembles.
  • PublishOnPyPI requires Package, whose wheel and source distribution it uploads.

  !failure() && !cancelled() is kept alongside, so a failure anywhere in the closure still suppresses these
  jobs; the new terms only close the skip. None of the producers is switchable by a caller input, so this cannot
  disable a supported configuration.

  IntermediateCleanUp and ArtifactCleanUp are unchanged on purpose — they delete artifacts and must run
  whatever happened — as are TriggerTaggedRelease and ReleasePage, which download nothing.

• CompletePipeline.yml publishes to GitHub Pages only from branches the github-pages environment admits —
  the repository's default branch and dev. The environment's protection rules reject a deployment from any other
  branch before a runner is assigned, so the job failed after one second with no step recorded:

  Branch "claude/dependency-updates" is not allowed to deploy to github-pages due to environment protection rules.
  

  Every feature-branch pipeline therefore showed a red job unrelated to its own changes, which is how a real
  failure gets overlooked. The condition reads github.event.repository.default_branch, so repositories on
  master are covered too. (CompletePipeline: publish Pages only from branches the environment admits #249)

• A jsonschema test dependency lost every MSYS2 job at the install step, before a single test ran.
  jsonschema depends on rpds-py, a Rust extension with no wheel for mingw_x86_64_ucrt_gnu; maturin refuses
  the target outright, so installing a Rust toolchain would not have helped. MSYS2 ships
  mingw-w64-<env>-python-jsonschema prebuilt, so the rewrite table names it. (Install 'jsonschema' from pacman on MSYS2 and unify both pacboy tables #252)

• Two rewrite-table entries in ApplicationTesting.yml could never match. The lookup is
  regExp.match(dependency.lower()), but that copy spelled "pyEDAA.ProjectModel" and "pyEDAA.Reports" in
  camel-case. A workflow requiring pyEDAA.Reports got none of python-ruamel-yaml, python-ruamel.yaml.clib or
  python-lxml on MSYS2. pyEDAA.Reports and pyVersioning both use that workflow. (Install 'jsonschema' from pacman on MSYS2 and unify both pacboy tables #252)

• A dependency list in requirements was silently dropped. The parameter accepts either -r <path> or a
  space separated list, but only the -r branch wrote to GITHUB_OUTPUT. The install step then ran pip install
  with an empty argument, installing nothing, and on MSYS2 the pacboy step scanned the empty string and annotated
  Unrecognized dependency format ''. It stayed hidden because the default is '-r ./requirements.txt'. (Extract the pip to pacboy translation into two composite actions #253)

• PrepareJob.yml and PublishReleaseNotes.yml compared a literal string. Both wrote "{FATHER_SHA}" == ""
  without the $, so that half of the emptiness check never fired. It was masked by the $? -ne 0 test beside
  it, which catches the case that actually occurs.

Documentation

• doc/Development.rst, Conditional Jobs → Guidelines, states the distinction between an unrelated dependency
  and a producing one, with the observed failure as the worked example. The rule is not obvious from the symptom.

• doc/Deveopment.rst was missing an l and is renamed to doc/Development.rst; the toctree entry in
  doc/index.rst follows. The page's title, its DEV/*** labels and every :ref: to them are untouched, so no
  cross-reference breaks — but the published URL changes from .../Deveopment.html to .../Development.html.
  The heading of doc/Instantiation.rst read "Instantiantion". (Fix two documentation typos: Deveopment.rst and 'Instantiantion' #255)

• UnitTesting.rst and ApplicationTesting.rst said that mingw_requirements "is not resolved this way" and is
  "passed to pip install unchanged". Both now state that it is resolved and checked like requirements, and
  that leaving it empty installs requirements on MSYS2 as well. (Extract the pip to pacboy translation into two composite actions #253)

• StaticTypeCheck.rst gains the three directory inputs, and its requirements section gains the same two-way
  lookup description the two testing templates carry. Its Behavior list says mypy runs in root_directory.
  (Give StaticTypeCheck directory inputs and the './' requirements syntax #257)

• Every instantiation example and every prose mention of the release branch moves from @r7 to @r8 — 163
  occurrences across 26 files, including the generic some/path/to/a/template placeholder. Same shape as
  c054718 ("Changed documentation to @r6.") for the previous major.

GitHub Pipeline

• _Checking_Parameters.yml gains a Requirements_Check job. It writes a small requirements tree —
  including a nested -r ./more.txt and a separate MSYS2 override — runs both new actions over it and asserts all
  three outputs, twelve pacboy packages among them. It refers to the actions as ./.github/actions/..., so it
  exercises the branch under test rather than @dev. (Extract the pip to pacboy translation into two composite actions #253)

  It is a control, not a smoke test: re-introducing the camel-case key drops python-lxml:p, and passing
  mingw_requirements through unresolved leaves the ./ path in place. Both were tried.

  It also resolves StaticTypeCheck.yml's new default against this repository's own tests/typing and asserts
  it equals the old literal default, so "both defaults name the same file" is checked rather than claimed — and
  the existence check runs against a file that really is there. (Give StaticTypeCheck directory inputs and the './' requirements syntax #257)

Known Issues

• MSYS2's python-ruamel-yaml is 0.18.17, while pyTooling requires ruamel.yaml ~= 0.19.1: pacman satisfies
  the import, then pip still sees the version unsatisfied. The same shape as the existing
  aiohttp >= 3.12 # limited on MSYS2 note.
• ruamel.yaml 0.19 replaced clib with clibz, and MSYS2 packages clib but not clibz. The entry is correct
  today and will want revisiting when MSYS2 catches up.
• Nothing keeps the rewrite table in sync with the packages it describes. It is a claim about other
  repositories' dependency graphs, and it had gone stale in six places before this release without a sound. A
  GitHub runner cannot check it — the sibling repositories are not there — so it wants a local tool rather than a
  CI job.

---

Related Issues and Pull-Requests

• Follows v7.15.0 (v7.15.0 #244).
• Merged into this release: CompletePipeline: publish Pages only from branches the environment admits #249, Install 'jsonschema' from pacman on MSYS2 and unify both pacboy tables #252, Extract the pip to pacboy translation into two composite actions #253, Fix two documentation typos: Deveopment.rst and 'Instantiantion' #255, Give StaticTypeCheck directory inputs and the './' requirements syntax #257.
• The same artifact-producer defect and the same fix in GHDL's pipeline:
  ghdl/ghdl#3313.

Important

This is a major release, so r8 has to be created after merging — r7 is not moved. Every consumer
pinning @r7 stays on v7.15.0 until its pipeline is deliberately changed to @r8. That is twenty pipelines
across this collaboration.

The documentation published from dev already tells consumers to use @r8, so the examples name a ref that
cannot be resolved until the branch exists. The window closes when the release is tagged.

Note

Why 8.0.0 rather than 7.16.0. Two changes alter the meaning of an existing parameter rather than adding
one: a ./-prefixed mingw_requirements in the two testing templates (#253), and a ./-prefixed
requirements in StaticTypeCheck.yml (#257). Both are now resolved against a test directory instead of the
working directory.

Neither affects any pipeline in this collaboration — CompletePipeline.yml does not expose mingw_requirements
at all and does not forward requirements to StaticTypeCheck, and the handful of repositories that set either
parameter directly all spell their paths without the ./ prefix. But both change a documented contract, and an
external consumer cannot be surveyed the way this workspace can.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.00% coverage variation

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

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (958de9e)	Report Missing	Report Missing	Report Missing
Head commit (8e631fc)	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 (#248)	1	1	100.00%

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%

¹ 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.}