Skip to content

[3006.x] Add onedir package test for libyaml-linked PyYAML - #70000

Merged
dwoz merged 5 commits into
saltstack:3006.xfrom
dwoz:dwoz/pkg-test/69907-libyaml-onedir
Aug 12, 2026
Merged

[3006.x] Add onedir package test for libyaml-linked PyYAML#70000
dwoz merged 5 commits into
saltstack:3006.xfrom
dwoz:dwoz/pkg-test/69907-libyaml-onedir

Conversation

@dwoz

@dwoz dwoz commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Follow-up to PR #69950 (3006.x) / #69949 (3008.x) — adds a package-level regression test so a slip back to a source-built PyYAML without libyaml (the class of bug reported in #69907) fails CI before release.

What it checks, from the shipped onedir python:

  • yaml.CSafeLoader, yaml.CSafeDumper, yaml.CLoader, yaml.CDumper are all present
  • import _yaml succeeds (PyYAML C extension is importable)
  • salt.utils.yamlloader.SafeLoader is yaml.CSafeLoader — catches the case where the extension exists but Salt's shim is still resolving to the pure-Python loader
  • Round-trips a trivial YAML doc through CSafeLoader to make sure the extension is functional, not just importable

Linux-only. Windows and macOS onedirs do not pass --no-binary=:all: to pip, so they already pick libyaml-linked wheels.

Regression cover for saltstack#69907 / PR saltstack#69950 (3006.x) / saltstack#69949 (3008.x).
Spawns the onedir python and asserts yaml.CSafeLoader/CSafeDumper and
the _yaml C extension are present, plus salt.utils.yamlloader.SafeLoader
resolves to yaml.CSafeLoader. Linux-only; Windows/macOS onedirs already
pick libyaml-linked wheels because they do not pass --no-binary=:all:
to pip.
twangboy
twangboy previously approved these changes Aug 10, 2026
salt.utils.yamlloader exports BaseLoader (which resolves to
yaml.CSafeLoader when libyaml is linked), not SafeLoader. The initial
test used the wrong name and hit AttributeError on every Linux runner.
Assert against BaseLoader instead.
@dwoz

dwoz commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

Skip the two libyaml onedir tests on the downgrade flavor (install_salt.downgrade). The downgrade matrix rolls back to the pre-#69950 onedir before pytest runs, so libyaml is legitimately absent — asserting its presence there was a false positive. Install+upgrade flavors still exercise the fix.

…owngrade

Post-downgrade pytest re-enters the pkg/integration suite with the
previous salt onedir on disk and no --downgrade flag, so the earlier
install_salt.downgrade guard didn't trigger and the test still failed.

Rewritten to key on install_salt.version:
- >= 3006.28 -> assert libyaml present (guards the fix)
- <  3006.28 -> assert libyaml absent (documents the pre-fix baseline
  so a silent regression on the old branch is also caught)

Works uniformly across the three pkg-test flavors without skips.
The prior design compared install_salt.version >= Version("3006.28") to
predict whether libyaml should be present, but dev builds report
'3006.27+NNN.gSHA' which packaging.version orders BEFORE '3006.27' let
alone '3006.28' (PEP 440 local-version segment). That flipped the
expected-libyaml boolean to False on install jobs and turned every
Linux install matrix row red.

install_salt.use_prev_version is True iff the pytest run is executing
against the downgraded-to previous release (set by --use-prev-version in
the post-downgrade validation stage). That's the only flavor where the
onedir predates PR saltstack#69950 and libyaml is legitimately absent. Key the
expectation off that flag and drop the version-comparison plumbing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test:full Run the full test suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants