mirror of
https://github.com/logos-co/logos-package-manager.git
synced 2026-08-27 10:11:07 +00:00
Dario Lipicar
ce93414377
* doctest(lgpm-cli): mark the platforms, so the run half can execute on Windows
The spec's build section needs nix; everything after it drives the binary that
section produced and runs anywhere. Marking that is what lets a real Windows
runner execute the second half and publish a report beside the ubuntu and macos
ones, instead of the hand-written smoke script it replaces.
Build the lgpm CLI platform: [linux, macos] (nix)
Detect the platform variant platform: [linux, macos] (uname)
The platform variant, on Windows platform: windows (stated, not probed)
everything else unmarked -- runs on every leg
The Windows variant section is the interesting one. `uname` is how you find this
machine's variant when standing on it; a cross-built Windows run already knows
which target it was built for, and MSYS's `uname` answers with something the
existing case has no arm for. Stating it is the same call I had made twice by
hand in smoke scripts -- now it lives in the spec, where `generate` will render
it into the tutorial as the genuinely useful "on Windows, do this instead".
Two other changes, both measured rather than stylistic:
* `tar --format=ustar` at all four sites. bsdtar's default is restricted pax and
emits a PaxHeader entry for a sub-second mtime -- which every file here has --
and lgpm's tar reader cannot parse them, so the package fails to load. Isolated
on macOS by building the same tree three ways: pax without AppleDouble FAILS,
pax with it FAILS, ustar OK. Windows ships bsdtar as System32\tar.exe, so this
is not a macOS quirk; GNU tar 1.35 accepts the flag and emits no pax either.
* `./cli/bin/lgpm{exe}` instead of `./lgpm/bin/lgpm`, and `-o cli`. {exe} is
empty on unix and `.exe` for a Windows target, and naming the result dir after
the flake output makes it match the staged tree the Windows job produces --
one directory per target. Together they remove the path translation a CI job
would otherwise have to do.
DEPENDS ON logos-doctest support for `platform:` being merged first. Its master
has none, and doctests.yml runs `nix run github:logos-co/logos-doctest`, so
landing this before that would make both variant sections run on every leg --
the windows one overwrites the unix one and the install fail-closes. Measured:
7 passed, 1 failed. Held on its own branch rather than on the Windows CI PR for
exactly that reason.
Verified with the pending doctest: 13 passed / 1 skipped on macos with no
--platform flag at all, and the generated Windows leg runs standalone to 12
records with 0 failures.
* ci(windows): run the lgpm-cli doctest's exercise half on real Windows
doctests/lgpm-cli.test.yaml has 13 `run:` steps and exactly ONE invokes nix.
The other 12 only drive the built binary, and the nix one needs no translation
either: `targets: cli` in this workflow IS it. So the doc-tested install
lifecycle -- hand-build two .lgx packages, install both, read the index back,
query the dependency graph -- now runs on a real windows-latest runner without
doctest.py, which cannot run there, having to change at all.
Everything except this file lives in logos-co/logos-windows-ci@v1.
Two things needed a decision rather than a translation, both measured:
1. THE PLATFORM VARIANT. The spec probes with `uname` and has no Windows arm,
exiting 1 there. Here the variant is not unknown -- we built FOR this target
-- so it is stated: windows-x86_64-dev, the name a dev build of lgpm derives
for itself. The install step is what actually exercises it, because lgpm
fail-closes on a package carrying no payload for the platform it is running
on. That refusal is the thing standing between a Windows package and being
installed as a Linux one, so a green install is the real assertion here.
2. `tar --format=ustar`, WHICH IS LOAD-BEARING. bsdtar's default is "restricted
pax": it emits a PaxHeader entry whenever a file needs something ustar cannot
express, and a SUB-SECOND MTIME is enough -- which every file this script
writes has. lgpm's tar reader cannot parse those entries and the package
fails to load. Isolated on macOS (bsdtar 3.5.3) by building the same tree
three ways: pax present + no AppleDouble -> install FAILS; pax present +
AppleDouble -> install FAILS; ustar -> install OK. So the pax entries are the
cause on their own.
It is not a macOS quirk: Windows ships bsdtar as System32\tar.exe, and which
tar an MSYS bash resolves is a PATH question nobody has answered on the
runner. GNU tar 1.35 accepts --format=ustar and emits no pax entries either,
so naming the format costs nothing and removes the question. The spec's plain
`tar -czf` carries the same latent fragility.
Verified against a native build, with controls so the assertions are known to
bite: clean run 0; a wrong expected string 1; a missing binary 1; and dropping
--format=ustar 1, which is what proves that line is doing work.
NOT verified: this has never run on a runner. logos-package is the only caller
that has, and lgx is Qt-free just as lgpm is, so this exercises the reusable
path rather than re-testing lgx.
* ci(windows): the Windows leg is a doc-test leg, publishing beside ubuntu/macos
Replaces this branch's earlier shape -- a separate windows.yml plus a
hand-written .github/smoke/lgpm-cli.sh -- with one job in doctests.yml that
calls logos-windows-ci with the spec itself.
windows:
uses: logos-co/logos-windows-ci/.github/workflows/windows-ci.yml@v1
with:
targets: cli
doctest-spec: doctests/lgpm-cli.test.yaml
doctest-artifact: lgpm-doctest-reports
WHY IT IS A JOB HERE AND NOT ITS OWN WORKFLOW, which is the whole reason this
commit exists: actions/download-artifact scopes to the CURRENT WORKFLOW RUN
unless given a run-id and an elevated token -- its README says so outright. A
report uploaded by a separate windows.yml is therefore invisible to
publish-report, and adding `windows-latest` to that job's OS loop would have
been necessary but useless. Same run, same artifact namespace, no cross-run
plumbing. Both publish loops gain the name as well.
windows.yml is DELETED rather than kept alongside. The reusable workflow
cross-builds the target, gates the PE format and the import closure, hands the
tree to a real windows-latest runner and executes there -- everything that file
did -- so keeping it would only buy a second Windows cross-build per PR.
.github/smoke/lgpm-cli.sh is deleted too. It duplicated the spec's commands and
assertions by hand, which drift; and it could only ever produce a pass/fail,
never a report anyone could read afterwards. The generated script is emitted
from the spec on the builder, so the two cannot disagree.
Depends on the commit below it, which marks the spec's platforms, and on
logos-windows-ci@v1 carrying doctest-spec support.
Rehearsed locally end to end against this spec: 12 steps generated, the script
ran standalone to 12 records / 0 failures, assemble and report produced a 27 KB
index.html -- the artifact publish-report consumes. actionlint clean.
NOT verified: this has not run on a runner.
* ci: download only the report artifacts in publish-report
The step had no `name:` and no `pattern:`, so it pulled every artifact in the
run. That was fine when the run held two reports; it now also holds the Windows
job's staged tree -- lgpm.exe and its 18 DLLs -- and the raw execution records,
neither of which this job reads.
`pattern: lgpm-doctest-reports-*`, which download-artifact@v4 already supports;
no version bump involved. Each artifact still lands in artifacts/<name>/, which
is the layout the loop below expects, so nothing else changes.
* ci: re-run against logos-windows-ci@v1 with the wine leg gated off
The wine leg cannot execute a generated doctest script -- it calls the PE
directly and bash on Linux exits 126 -- so v1 now skips it when doctest-spec is
set. The native leg, which is the one that counts, already passed.