Improve ci.yml, enhance testability, and document the testing process
#41
Conversation
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
Changes: - Remove the needless `preflight_check_dists` job - Merge the wheel testing step into upload_to_testpypi - Add the use of `check-wheel-contents` to the tests - Make various changes to better support local testing - Simplify some of the workflow syntax used
Update and add more details about the testing process.
If an error is reported, it's easier if it's obvious which of the two programs produced it.
This will make the command show up in the run log as its own entry, making it easier to locate in the output.
Some of the settings for building wheels can be put into `pyproject.toml`. This fits with current best practices and lets us further simplify `ci.yml`.
Turns out `vars.local_testing` is never needed.
`check-wheel-contents` complains about the wheel only on Windows and not other architectures. I suspect there is a bug in `check-wheel-contents`. Better to skip it for now.
mhucka
changed the title
ci.yml, enhance testability, and document the testing process
mhucka
added
the
devops
I can't think of a good reason to cause the job to fail if an existing file from the same release is already on pypi. This might happen if you try to rerun the workflow because of a failure during one of the files. Let's just let it give a warning and move on.
I realized that the values should be left unset in the default case.
Strilanc
reviewed
Nov 4, 2025
In principle, that variable shouldn't need to be set. Let's try removing it.
Few people will want or need to test the test.pypi upload parts, yet it complicated the instructions considerably. Let's skip that and focus on the basics of running the other workflow jobs locally for testing.
Pin the version of the act runner Docker image in the instructions to a specific hash.
We don't need to tell people to create `/tmp/act-artifacts`.
Go back to using the ubuntu-24.04 image rather than try to make do with a smaller one. Also, add a couple more missing items to the Dockerfile for building a customized local image. Also, provide the `--no-recurse` flag to the invocation of `act`. That flag shouldn't be necessary when using `-W`, but if the user starts experimenting with changing the arguments, showing `--no-recurse` in the example may help steer them in a direction that leads to fewer mysterious problems.
mhucka
force-pushed
the
mh-more-ci-work
branch
from
4113711 to
fd3e294
Compare
What I wrote is misleading; Docker will use all CPU cores by default if the application is such that it can use parallism, and the purpose of `--cpus` is actually to limit the number of cores it uses. Let's just let it uses its defaults.
Strilanc
approved these changes
Nov 7, 2025
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
mhucka
added a commit
that referenced
this pull request
Dec 1, 2025
…ss (#41) Changes: * Move more `cibuildwheel` settings into the `pyproject.toml` file, which both aligns with recommended practices and allows simplifications to `ci.yml`. * Get rid of `preflight_check_dists` job in `ci.yml` and make the `twine check` step be part of the `upload_to_testpypi` job. This simplifies and streamlines the workflow. * Get rid of references to `vars.ACT` in `ci.yml`, which turn out to be unnecessary. * Enhance local testability by adding support for using a local pypi server for testing in the `upload_to_testpypi` job. * Add an input variable `upload_to_pypi` to `workflow_dispatch` invocations to allow control over whether the upload to `pypi.org` is done during manual invocations. * Set `skip-existing` to `true` when using `actions/gh-action-pypi-publish` so that partial reruns of the workflow are possible. * Use explicit versions of runners instead of `-latest`. * Make miscellaneous small tweaks to `ci.yml`. * Add a README file to `.github/workflows/` detailing how to do local testing of `ci.yml`, to document the process.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Changes:
Move more
cibuildwheelsettings into thepyproject.tomlfile, which both aligns with recommended practices and allows simplifications toci.yml.Get rid of
preflight_check_distsjob inci.ymland make thetwine checkstep be part of theupload_to_testpypijob. This simplifies and streamlines the workflow.Get rid of references to
vars.ACTinci.yml, which turn out to be unnecessary.Enhance local testability by adding support for using a local pypi server for testing in the
upload_to_testpypijob.Add an input variable
upload_to_pypitoworkflow_dispatchinvocations to allow control over whether the upload topypi.orgis done during manual invocations.Set
skip-existingtotruewhen usingactions/gh-action-pypi-publishso that partial reruns of the workflow are possible.Use explicit versions of runners instead of
-latest.Make miscellaneous small tweaks to
ci.yml.Add a README file to
.github/workflows/detailing how to do local testing ofci.yml, to document the process.