Repository navigation
CI: run the jobs a change can reach - #352
Merged
Merged
Conversation
…ing, a weekly run checks everything
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.
Lint, Test CPython and Clean standalone build each ran in full for every change that wasn't plain docs: about 80 runner-minutes per run, on both the pull request and the push to main. A release bump (
VERSIONandCHANGELOG.md) ran all of it, and so did a one-line example edit.What changes
tools/ci_scope.pydiffs a pull request against its base and a push to main from the commit main was at before the push, and sets four outputs:lint,unit(the CPython matrix),wheels(cibuildwheel on macOS and ARM, the[render]extra) andbuild(the MicroPython unix build, the float cell, CMake configure). Each job gates on its output with a job-levelif:.VERSIONreaches nothing: the tests read__version__from the file and compare it with no number. An example reaches only lint. A unit test reaches lint and the CPython matrix, not the interpreter build or the wheel jobs. A pump or parity probe reaches lint, the matrix and the build, not the wheel jobs.tests/circuitpythonandtests/cmakereach only the build. Each workflow file reaches its own jobs; the release workflows reach none of them.src/,third_party/,lib/,setup.py,pyproject.toml,MANIFEST.in, the make and cmake files, the pins, a path no rule names, and the scope tool itself check every job. So does a manual run, a scheduled run, or a base git can't find (all zeros, or gone after a force push).paths-ignorestays).Replay
The last 25 commits on main, each compared with its first parent, which is what the push of that merge sees. Minutes are the job minutes of the real push runs, and "after" counts the jobs the new scope keeps (each workflow's scope job adds about a minute).
VERSION,CHANGELOG.md)tests/parity)Together: 1783 runner-minutes before, about 1270 after, a saving of 29 percent on this stretch. Most recent work is in
src/, which can reach everything, so the saving is the release bumps. The pull requests for those bumps save the same again.Planted faults
examples/audiodsp_simpletest.py: the scope keepslintonly, and flake8 fails (F821).tests/test_cpython_audiomath.py: the scope keepslintandunit, and the unit run fails.src/keeps all four.Testing
tests/test_ci_scope.py(12 tests) holds the rules, the union over files, the fallbacks and the outputs file. actionlint reports the same five shellcheck notes on the old workflows and the new ones, none from these edits. This PR changes the workflows and the tool, so its own CI run is full.