Skip to content

v8.0.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 08 Sep 06:54
· 38 commits to dev since this release
v8.0.0
04f49c7

New Features

  • Two composite actions carry logic that both testing job templates used to hold a copy of (#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. (#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.
    (#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. (#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. (#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. (#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. (#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. (#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. (#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. (#253)

  • The computed pacboy list is sorted, so the same job produces the same line on two runs and logs can be
    diffed. (#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. (#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. (#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. (#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. (#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'. (#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". (#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. (#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.
    (#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. (#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. (#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

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.

Published from Verification of Pipeline Templates (Simple Package) workflow triggered by Paebbels on 2026-09-08 06:54:25 UTC.

This automatic release was created by pyTooling/Actions::Release.yml

Contributors

r6
Assets 2
Loading