Skip to content
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

Closed
brettcannon opened this issue Feb 5, 2017 · 8 comments
Closed

Only run CI checks when appropriate files have changed #14

brettcannon opened this issue Feb 5, 2017 · 8 comments
Labels

Comments

@brettcannon
Copy link
Member

E.g. don't run code coverage or the test suite if only the docs changed (or vice-versa).

@berkerpeksag
Copy link
Member

This is now done. @brettcannon could you please close this?

Side note: Should we allow "Core developers" team to close issues on this repo?

@brettcannon
Copy link
Member Author

Closed and now the core team has write permissions (just simply forgot to add the team).

@brettcannon
Copy link
Member Author

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. 😄

ncoghlan pushed a commit to python/cpython that referenced this issue Feb 19, 2017
* 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)
ncoghlan pushed a commit to python/cpython that referenced this issue Feb 19, 2017
* 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)
@ammaraskar
Copy link
Member

I don't think the Doc only test works. See this PR here: python/cpython#3072
The travis run: https://travis-ci.org/python/cpython/builds/263366915 (and it's console log)

It triggered a full code rebuild and test even though the only thing that has changed is Doc/library/socket.rst

@brettcannon brettcannon reopened this Aug 11, 2017
@brettcannon
Copy link
Member Author

It was working but it seems something has changed such that it didn't succeed in this case.

@ammaraskar
Copy link
Member

ammaraskar commented Aug 18, 2017

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:

  1. git clone --depth=50 https://github.com/ammaraskar/cpython.git
  2. git fetch origin +refs/pull/5/merge
  3. git checkout -qf FETCH_HEAD

I replicated these commands locally and ran git log and the problem became obvious. Github in their special refs/pull/*/merge branch creates a merge commit which means at that point this git log looks something like:

commit 472056eb60b0601dcded798229bebbddfd307945 (HEAD)
Merge: b072c6d0c6 86cece89d5
Date:   Fri Aug 18 05:43:43 2017 +0000

    Merge 86cece89d5c6452a92004af0276147187034d41f into b072c6d0c69849690ff03c0ce4f1911139b02ce6

commit b9ff498793611d1c6a9b99df464812931a1e2d69 (master)
Author: Elmar Ritsch <35851+elritsch@users.noreply.github.com>
Date:   Fri Aug 18 05:23:51 2017 +0200

    Fix broken `Show Source` links on documentation pages (GH-3113)

    The `Show Source` was broken because of a change made in sphinx 1.5.1
    In Sphinx 1.4.9, the sourcename was "index.txt".
    In Sphinx 1.5.1+, it is now "index.rst.txt"

...
EVERY SINGLE COMMIT TO
MASTER ON A TIME AFTER
MY PR COMMIT DATE
...

commit 86cece89d5c6452a92004af0276147187034d41f
Author: Ammar Askar <ammar@ammaraskar.com>
Date:   Sat Aug 12 15:15:07 2017 -0400

    Fix Linux availability version for SO_PEERSEC

And so the git diff picks up on all the commits in the middle because the PR commit ends up in a really old slot in history.

@brettcannon
Copy link
Member Author

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.

@ammaraskar
Copy link
Member

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.

ammaraskar added a commit to ammaraskar/cpython that referenced this issue Jan 26, 2018
…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
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jan 27, 2018
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)
berkerpeksag pushed a commit to python/cpython that referenced this issue Jan 27, 2018
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
berkerpeksag pushed a commit to python/cpython that referenced this issue Jan 27, 2018
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants