-
-
Notifications
You must be signed in to change notification settings - Fork 59
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
Only run CI checks when appropriate files have changed #14
Comments
This is now done. @brettcannon could you please close this? Side note: Should we allow "Core developers" team to close issues on this repo? |
Closed and now the core team has write permissions (just simply forgot to add the team). |
And thanks for the change! I'm sure not only PR submitters appreciate the faster turn-around but I bet Travis appreciates us using less free resources. 😄 |
* Add .travis.yml to 3.6 branch * Travis CI: run rstlint.py in the docs job (#68) Currently, http://buildbot.python.org/all/buildslaves/ware-docs buildbot is only run as post-commit. For example, bpo-29521 (PR#41) introduced two warnings, unnotified by the Travis CI docs job. Modify the docs job to run toosl/rstlint.py. Fix also the two minor warnings which causes the buildbot slave to fail. * Only run CI checks when appropriate files have changed (#74) Closes python/core-workflow#14 * Use 'make check' instead of 'python3 tools/rstlint.py' (#96)
* Add .travis.yml to 3.5 branch * Only run CI checks when appropriate files have changed (#74) Closes python/core-workflow#14 * Travis CI: run rstlint.py in the docs job (#68) Currently, http://buildbot.python.org/all/buildslaves/ware-docs buildbot is only run as post-commit. For example, bpo-29521 (PR#41) introduced two warnings, unnotified by the Travis CI docs job. Modify the docs job to run toosl/rstlint.py. Fix also the two minor warnings which causes the buildbot slave to fail. * Use 'make check' instead of 'python3 tools/rstlint.py' (#96)
I don't think the Doc only test works. See this PR here: python/cpython#3072 It triggered a full code rebuild and test even though the only thing that has changed is |
It was working but it seems something has changed such that it didn't succeed in this case. |
I've done some investigating and this is due to how Travis gets the merged code from Github. Following the sequence of commands it used to get the repo here, it went:
I replicated these commands locally and ran
And so the |
OK, so it's basically it's imperfect but isn't hurting anything. Thanks for the detailed report, @ammaraskar ! I'm going to close this again and we can just live with occasionally building more than necessary. |
There's a way around it, I opened up a PR to fix it: python/cpython#3129 Whether it's worth the added complexity to the build process, that I don't know. |
…er commits. Travis when merging changes from a pull request onto the target branch does not perform a rebase, instead it does a simple merge which causes the PR commits to retain their commit dates. This means that the commit log can potentially look like: PR merge <-- HEAD normal master commit <- master more commits from normal workflow PR commit 1 another master commit PR commit 2 Performing a git diff from PR commit 2 to master will accidentally include files that should not be there. Closes python/core-workflow#14
Travis when merging changes from a pull request onto the target branch does not perform a rebase, instead it does a simple merge which causes the PR commits to retain their commit dates. This means that the commit log can potentially look like: PR merge <-- HEAD normal master commit <- master more commits from normal workflow PR commit 1 another master commit PR commit 2 Performing a git diff from PR commit 2 to master will accidentally include files that should not be there. Closes python/core-workflowGH-14 (cherry picked from commit b2ec361)
Travis when merging changes from a pull request onto the target branch does not perform a rebase, instead it does a simple merge which causes the PR commits to retain their commit dates. This means that the commit log can potentially look like: PR merge <-- HEAD normal master commit <- master more commits from normal workflow PR commit 1 another master commit PR commit 2 Performing a git diff from PR commit 2 to master will accidentally include files that should not be there. Closes python/core-workflow#14
Travis when merging changes from a pull request onto the target branch does not perform a rebase, instead it does a simple merge which causes the PR commits to retain their commit dates. This means that the commit log can potentially look like: PR merge <-- HEAD normal master commit <- master more commits from normal workflow PR commit 1 another master commit PR commit 2 Performing a git diff from PR commit 2 to master will accidentally include files that should not be there. Closes python/core-workflow#14 (cherry picked from commit b2ec361)
E.g. don't run code coverage or the test suite if only the docs changed (or vice-versa).
The text was updated successfully, but these errors were encountered: