CI: build and test on FreeBSD, OpenBSD and NetBSD - #20
Open
neilpang wants to merge 2 commits into
Open
Conversation
tools/abiname.sh created its temporary file with a three-X mktemp template. GNU mktemp accepts that, but BSD mktemp(1) requires at least six Xs and fails with "insufficient number of Xs in template", which made the Makefile abort with "Could not determine platform". Use a six-X template, which is valid for both.
Add a separate workflow that builds the library and runs the full test suite on the three BSDs in a real VM, using the vmactions VM actions on the ubuntu-latest runner. The existing workflow is left untouched. No new ABI, assembly file or platform.h branch is needed: the BSDs on amd64 use the same sysv_amd64 ABI as Linux, and the existing ELF paths in the assembly sources apply unchanged. Consequently the jobs do not upload a library artifact, which would only duplicate the Linux one. GNU make is installed in the prepare step because the Makefile uses GNU make syntax while the BSD base system make is bmake. Closes stackless-dev#15
There was a problem hiding this comment.
Pull request overview
This PR adds CI coverage for the *BSDs (FreeBSD/OpenBSD/NetBSD) on amd64 by introducing a dedicated GitHub Actions workflow, and fixes a portability issue in the ABI detection helper script so those CI jobs can run successfully.
Changes:
- Fix
tools/abiname.shtemp-file creation to be compatible with BSDmktemp(1)by using a 6-Xtemplate. - Add
.github/workflows/buildbsd.ymlto build and run the full test suite in FreeBSD/OpenBSD/NetBSD VMs usinggmake. - Update README and CHANGELOG to document the new CI workflow and BSD coverage.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tools/abiname.sh | Makes ABI detection portable to BSD mktemp(1) by using a 6-X template. |
| .github/workflows/buildbsd.yml | New CI workflow running gmake all + gmake test in FreeBSD/OpenBSD/NetBSD VMs. |
| README.md | Adds a CI badge and clarifies BSD support expectations (sysv_amd64 + gmake). |
| CHANGELOG.md | Records the new BSD CI workflow and the mktemp portability fix under Unreleased. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #15
The issue anticipated new assembly, a
platform.hbranch and possible OpenBSDW^Xtrouble. In practice none of that was needed -- the three BSDs on amd64 already resolve to the existingsysv_amd64ABI, and the ELF paths in the assembly sources apply unchanged. Only one real portability bug stood in the way.What changed
1.
tools/abiname.sh-- ABI detection was broken on the BSDsThe temp file was created with a three-
Xmktemptemplate. GNUmktempaccepts that; BSDmktemp(1)requires at least six and fails:Changed to a six-
Xtemplate, which is valid for both. This is the only source change, and it is what the BSD jobs could not be green without.2. New
.github/workflows/buildbsd.ymlA separate workflow, so
buildcommit.ymlis untouched. Three jobs running in real VMs viavmactions/*-vmonubuntu-latest;gmakeis installed inpreparebecause the Makefile is GNU-make syntax while the BSD basemakeis bmake.The jobs do not upload a library artifact: the ABI is
sysv_amd64, identical to the Linux job's, so an artifact would only duplicate it (and collide on the artifact name).3. README / CHANGELOG -- platform list, a badge for the new workflow, changelog entries.
CI evidence
Both runs are on the exact head commit of this PR (
8febe73):abiname.shedit -- all 10 jobs green (Linux x5, macOS x2, Windows x3): https://github.com/neilpang/stackman/actions/runs/30357371214What the BSD logs actually show:
make abinamesysv_amd64test_01-test_08+test_cc,*** All test suites passed ***sysv_amd64sysv_amd64test_static/test_asmNetBSD is worth noting: because its base compiler is gcc rather than clang,
test_staticcompiles the inline-assembly path instead of printingno static with external asm, so it exercises inline asm on a BSD -- coverage the clang-based BSDs and macOS do not give.Points for you to decide
W^X: the concern in the issue did not materialize. Worth being precise about why, rather than reading too much into the green check:stackmandoes not generate code at runtime, soW^Xis not implicated at all. The relevant OpenBSD mechanism isMAP_STACK, and the test suite switches ontomalloc'd stacks without making syscalls while switched, so it passes. A consumer that does syscall on a non-MAP_STACKstack could still be killed by the kernel. This PR proves the library builds and its tests pass; it is not a general guarantee for OpenBSD consumers.vmactions/*-vm@v1boots each project's current release (today: 15.1 / 7.9 / 10.1). That tracks upstream automatically but means a future BSD release could break the job without a commit here. Say the word if you would rather pinrelease:per job.