-
Notifications
You must be signed in to change notification settings - Fork 185
MNT add CI jobs to run integration tests for downstream projects: loky, joblib, distributed #236
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
MNT add CI jobs to run integration tests for downstream projects: loky, joblib, distributed #236
Conversation
Codecov Report
@@ Coverage Diff @@
## master #236 +/- ##
=======================================
Coverage 85.12% 85.12%
=======================================
Files 1 1
Lines 585 585
Branches 117 117
=======================================
Hits 498 498
Misses 63 63
Partials 24 24Continue to review full report at Codecov.
|
ogrisel
left a comment
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 tackling this. Here are some comments.
|
Mmh. So the good news is that there does not seem to be any syntax error. Also, |
this seems to fix test_duplicate_clients
No suggestion off the top of my head, sorry ... |
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.
Instead of running those integration tests as cron jobs, I am thinking we could run them conditionally whenever the commit message has a special flag. For instance, for the joblib entry:
commit_message =~ /(ci-downstream|ci-joblib)/https://docs.travis-ci.com/user/conditions-v1
WDYT?
|
This sounds great to tackle issues early. But it will be harder for us to spot a breaking change if we miss it initially. We would at least have to push empty commits with |
Yes but we can do that in a PR that we do not merge to avoid polluting master with empty commits. |
So be it. It's a tradeoff between long CI jobs, unwanted noisy notifications (in case the downstream master branches are failing randomly for causes unrelated to cloudpickle) and thinking about doing manual triggers prior to making a cloudpickle release. |
|
OK. I'll change the trigger and make a few test commits inside the PR with the appropriate flags. |
64a122b to
a3c86bb
Compare
ogrisel
left a comment
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.
Actually, changing my mind on the commit message tagging syntax:
9afceb6 to
f1c2196
Compare
f1c2196 to
cacd7a0
Compare
|
It seems to work. Can you just try with |
|
Did you cancel the |
Nope, actually I thought you did. Might be because of auto cancelling builds when more recent commits are pushed? |
|
Besides that the filter seems to work indeed. |
|
Good, let's wait for the final build to complete. |
|
Merged. Thanks @pierreglaser! |
This PR configures cron-jobs that build and launch the test suite of downtream projects that rely on
cloudpickle. The main purpose is to find out quickly if we introduce breaking changes.Ideally we would rather test the stable (PyPI) rather than the latest (master branch) version, but each time, a project-specific issue was making it at least clumsy, at worst impossible. (I can detail upon request).