-
-
Notifications
You must be signed in to change notification settings - Fork 275
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 improvements #1860
CI improvements #1860
Conversation
Pull Request Test Coverage Report for Build 3378006405
💛 - Coveralls |
cb80e3e
to
e08a47a
Compare
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.
I'm going to trust you on this one, I'm not an expert. The new hash key does make much more sense than manually upgrading the cache indeed. I wonder why I did not think of this when upgrading astroid in pylint,
You might want to take a look at pylint-dev/pylint#7651 then. It does simplify update astroid in pylint. The primer test failure there is expected. |
* Add check-latest to setup-python * Use pyproject.toml for hash
* Add check-latest to setup-python * Use pyproject.toml for hash
Description
Similar changes to pylint-dev/pylint#7651
restore-keys
. Especially on Windows there are issues with reusing old cache entries and trying to install newer versions. Those are just skipped if the old one still satisfies the requirement. It's easy / fast enough to create a whole new environment if something changes.check-latest: true
forsetup-python
action. This will prevent cache restore issue when runners use different Python patch versions. https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#check-latest-versionKEY_PREFIX
env variable to more easily identify the key prefix in each workflow.setup.cfg
withpyproject.toml
for file hash