-
-
Notifications
You must be signed in to change notification settings - Fork 552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI Build & Test: First build incrementally and test changed files only #35652
Changes from 6 commits
4451886
2881586
43fcf4a
f9b4412
f93a4d6
f46d247
cbc0198
b8b235c
f4a6ca0
29a3ae0
7d9af59
a0e18d9
36b9484
5d13d8f
2384f1d
f40fa16
c865882
21c5240
eb0ef34
a423367
506db04
9f30a8d
b13cbf4
136337c
a29d22e
004247c
2e5d4ce
908ad71
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -29,24 +29,52 @@ jobs: | |
id: checkout | ||
uses: actions/checkout@v3 | ||
|
||
- name: Prepare | ||
- name: Update system packages | ||
id: prepare | ||
run: | | ||
# Install test tools. | ||
if apt-get update && apt-get install -y git python3-venv; then | ||
# Debian-specific temporary code: | ||
# Installation of python3-venv can be removed as soon as a | ||
# base image with a release including #33822 is available | ||
: | ||
else | ||
export PATH="build/bin:$PATH" | ||
eval $(sage-print-system-package-command auto update) | ||
eval $(sage-print-system-package-command auto --spkg --yes --no-install-recommends install git) | ||
fi | ||
export PATH="build/bin:$PATH" | ||
eval $(sage-print-system-package-command auto update) | ||
eval $(sage-print-system-package-command auto --spkg --yes --no-install-recommends install git) | ||
|
||
- name: Incremental build and test | ||
if: always() && steps.prepare.outcome == 'success' | ||
id: incremental | ||
run: | | ||
set -ex | ||
git config --global user.email "[email protected]" | ||
git config --global user.name "Build & Test workflow" | ||
# If actions/checkout downloaded our source tree using the GitHub REST API | ||
# instead of with git (because do not have git installed in our image), | ||
# we first make the source tree a repo. | ||
if [ ! -d .git ]; then git config --global --add safe.directory $(pwd) && git init && git add -A && git commit --quiet -m "new"; fi | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Instead of this git acrobatics, why not get the list of changed files using say https://github.com/marketplace/actions/get-all-changed-files and then run the tests on each of them? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not just for finding the changed files. |
||
# Tag this state of the source tree "new". This is what we want to build and test. | ||
git tag -f new | ||
# Our container image contains a source tree in /sage with a full build of Sage. | ||
# But /sage is not a git repository. | ||
# We make /sage a worktree whose index is at tag "new". | ||
# We then commit the current sources and set the tag "old". (This keeps all mtimes unchanged.) | ||
# Then we update worktree and index with "git reset --hard". | ||
mkoeppe marked this conversation as resolved.
Show resolved
Hide resolved
|
||
# (This keeps mtimes of unchanged files unchanged and mtimes of changed files newer than unchanged files.) | ||
# Finally we reset the index to "old". (This keeps all mtimes unchanged.) | ||
# The changed files now show up as uncommitted changes. | ||
git worktree add --detach worktree-image | ||
rm -rf /sage/.git && mv worktree-image/.git /sage/ | ||
rm -rf worktree-image && ln -s /sage worktree-image | ||
(cd worktree-image && git commit --allow-empty -m "old" -a && git tag -f old && git reset --hard new && git reset old) | ||
# Now re-bootstrap and build. The build is incremental because we were careful with the timestamps. | ||
# We run tests with "sage -t --new"; this only tests the uncommitted changes. | ||
(cd worktree-image && ./bootstrap && make build && ./sage -t --new -p2) | ||
env: | ||
MAKE: make -j2 | ||
SAGE_NUM_THREADS: 2 | ||
|
||
- name: Configure new tree | ||
if: always() && steps.prepare.outcome == 'success' | ||
run: | | ||
# Reuse built SAGE_LOCAL contained in the Docker image | ||
./bootstrap | ||
./configure --enable-build-as-root --prefix=/sage/local --with-sage-venv --enable-editable --enable-download-from-upstream-url | ||
|
||
- name: Build and test modularized distributions | ||
if: always() && steps.prepare.outcome == 'success' | ||
run: make V=0 tox && make pypi-wheels | ||
|
@@ -91,7 +119,7 @@ jobs: | |
if: always() && steps.build.outcome == 'success' | ||
run: | | ||
../sage -python -m pip install coverage | ||
../sage -python -m coverage run ./bin/sage-runtests --all -p2 | ||
../sage -python -m coverage run ./bin/sage-runtests --all --long -p2 | ||
working-directory: ./src | ||
|
||
- name: Prepare coverage results | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this coming before the actual build/is this not building things twice now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, in fact, also run the main build on the incrementally updated source tree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this "incremental" build, what is build if one changes a python file, a cython file and say something in the build infrastructure (say a package update and a change in setup.py)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The git acrobatics has exactly the same effect as doing a "git checkout" to the new ref in a full build of the Sage distribution on a developer's computer: The timestamps (mtime) of unmodified files are kept the same, and the timestamps of modified files are newer than any file that was there before.
It is looking so complicated because the source tree in our Docker images is actually not a git working copy. This is why I have to turn it surgically into a working copy (without messing up the timestamps).
Running
make build
results in an incremental build: For spkgs, if the declared package version is changed, then (because they no longer match the installation records in{local,venv}/var/libs/sage/installed
these packages are reinstalled.For the Sage library, the normal in-tree editable build is run, which is incremental (only the modified Cython files are cythonized and the result compiled). Because we are using editable mode, nothing interesting is happening with the modified Python files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the details!
But doesn't this mean that sometimes the incremental build (+ test) fails? At least locally, I sometimes have to hard-reset everything and run the whole bootstrap + configure + make cycle. In this cases, the workflow would fail, right? I'm not sure if this then more confusing than helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my experience, incremental builds are very robust, with the following exceptions:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes, but most often I only have to run bootstrap & configure again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then I let someone else with more experience on the build process have a look at this PR. Since this is the most important build workflow, it should only fail for the correct reason and not because of some general issues related to the build process.
If the incremental build is not (yet) reliable enough, I would favor a normal build + test on changed files + long test; and/or extracting the incremental build to a new workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah OK. We can certainly run
bootstrap
manually before doing the incremental build. I'll make this change.(configure definitely does not have to be run manually.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tobiasdiez @kwankyu I have now implemented a fallback to non-incremental when the incremental build fails βΒ both for build and for docbuild.