3591 Use pip cache in GitHub Actions #967
No reviewers
Labels
No Label
Benchmarking and Performance
HTTP Storage Protocol
Nevow Removal
Python 3 Porting
not-for-merge
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: tahoe-lafs/tahoe-lafs#967
Loading…
Reference in New Issue
No description provided.
Delete Branch "3591.use-pip-cache-in-github-actions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ticket is https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3591.
Some notes:
We're using actions/cache here. Python-specific caching action requires pip 20.1+ because it implements
pip cache dir
command to get pip's cache directory in an OS-independent manner. There's no perceivable overall speedup in CI completion time because of caching (possibly because we're in a noisy shared environment), but we'd be hammering pypi much less often than before, which is nice.Since we have steps containing
pip install --upgrade codecov tox setuptools
, we'd be still downloading some packages from PyPI. We probably can do apip install codecov tox setuptools
instead, thus using cached versions of those packages, but I guess tracking their latest versions could be useful, because any breakage with them would surface early on.Piggy-backing on this PR is the removal of
git fetch --prune --unshallow
step, and addition offetch-depth: 0
parameter toactions/checkout
. Step with the former usually takes 10-20s, so avoiding that is nice.What's the point of doing some (allegedly) pointless caching without some (almost pointless) numbers? Well, we do have some numbers!
There's some meaningful difference in "installing Python packages" step, where we do a
pip install --upgrade codecov tox setuptools
for coverage tests, andpip install --upgrade tox
for integration and packaging tests. Comparing the tip of this PR branch (where caching enabled) versus base of this branch (where caching action is essentially a no-op):And here are the overall CI completion times, which are kind of all over the place:
Looks like the time-consuming step is the actual running of tests.
Codecov Report
Continue to review full report at Codecov.
LGTM.
Regarding the fetch-depth 0, I suspect that in the future some applications may require some depth (such as to resolve recent tags), but until that's needed, this approach seems suitable.
Thank you @jaraco!
Per actions/checkout documentation, a
fetch-depth
of 0 will fetch history for all tags and all branches. Tahoe-LAFS needs more git metadata than what's checked out by the defaultfetch-depth
of 1 to be able to populatesrc/allmydata/_version.py
, without whichallmydata.test.test_client.Basic.test_versions
will break.