{"action":"created","issue":{"url":"https://api.github.com/repos/travis-ci/travis-ci/issues/2548","repository_url":"https://api.github.com/repos/travis-ci/travis-ci","labels_url":"https://api.github.com/repos/travis-ci/travis-ci/issues/2548/labels{/name}","comments_url":"https://api.github.com/repos/travis-ci/travis-ci/issues/2548/comments","events_url":"https://api.github.com/repos/travis-ci/travis-ci/issues/2548/events","html_url":"https://github.com/travis-ci/travis-ci/issues/2548","id":38365649,"number":2548,"title":"Have a way to cancel a build if a newer commit happens","user":{"login":"toolforger","id":915906,"avatar_url":"https://avatars.githubusercontent.com/u/915906?v=3","gravatar_id":"","url":"https://api.github.com/users/toolforger","html_url":"https://github.com/toolforger","followers_url":"https://api.github.com/users/toolforger/followers","following_url":"https://api.github.com/users/toolforger/following{/other_user}","gists_url":"https://api.github.com/users/toolforger/gists{/gist_id}","starred_url":"https://api.github.com/users/toolforger/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/toolforger/subscriptions","organizations_url":"https://api.github.com/users/toolforger/orgs","repos_url":"https://api.github.com/users/toolforger/repos","events_url":"https://api.github.com/users/toolforger/events{/privacy}","received_events_url":"https://api.github.com/users/toolforger/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2014-07-22T03:17:19Z","updated_at":"2016-10-13T15:55:22Z","closed_at":"2014-07-22T04:54:00Z","body":"We (SymPy) have a use case that some of us tend to fire off a series of commits, never to notice that each and every of these commits causes a Travis build. Later, we tend to find that a lot of irrelevant commits have been tested but the latest and most interesting commit is still in the work queue; also, this wastes travis.org resources and we'd like to avoid that.\r\nWe're aware of [skip ci] but that does not cover the use case: we want to cancel builds that were already queued (no way to insert that [skip ci] tag into GitHub) but have become irrelevant.\r\nWe're also aware that one can always manually cancel builds, which covers the case of diligent developers but does not cover the sloppy ones who simply fire off the commits and aren't aware, don't care or are too distracted to realize that they just tied up considerable testing resources.\r\n\r\nI toyed with making the build script check for newer commits, and fail if it found there's a newer commit. I dropped that approach for several reasons:\r\n- Test builds become nonrepeatable (a repeat will now always fail once a newer commit happens).\r\n- The only way to cancel a build from the script is to return a nonzero status, which will cause the test to show up as \"failed\" (red markers). SymPy welcomes new contributors and GSoC participants, which means we'd burden people already taxed with learning technical details with yet another one, and one that may make them panic as well.\r\n- Also, I found it somewhat difficult to reliably detect that a newer commit on the same branch exists. This may be due to my inexperience with git, or with Travis, or with the way Travis pulls clones from the repository (the latter being something that may change without notice so I'm unsure whether this might not add maintenance load to SymPy).\r\n- If a test should be run anyway (because maybe the user wants to see which in a series of commits caused a failure), he can't do that on Travis, not even by rescheduling the test (it will fail due to newer commits).\r\n\r\nI'm not 100% sure what the best way to approach this request is. I can imagine different approaches:\r\na) Add an option to the project's Travis configuration files that specifically handles this case. Make sure that a rescheduled test does not do the check.\r\nb) Let the projects control that from their build scripts.\r\nb1) Provide more information to scripts: are there newer commits on the same branch (this may amount to a documentation snippet that tells people how to script that, and makes Travis CI contributors aware that they should make sure that this information isn't obscured by specifics of Travis CI's git clone/checkout machinery)? Is this a rescheduled run or the first one? (Possibly other info.)\r\nb2) Give scripts an option to return a \"cancelled without pass/fail conclusion\", showing up as a grey marker just like the cancels from the web interface do."},"comment":{"url":"https://api.github.com/repos/travis-ci/travis-ci/issues/comments/253556145","html_url":"https://github.com/travis-ci/travis-ci/issues/2548#issuecomment-253556145","issue_url":"https://api.github.com/repos/travis-ci/travis-ci/issues/2548","id":253556145,"user":{"login":"jakirkham","id":3019665,"avatar_url":"https://avatars.githubusercontent.com/u/3019665?v=3","gravatar_id":"","url":"https://api.github.com/users/jakirkham","html_url":"https://github.com/jakirkham","followers_url":"https://api.github.com/users/jakirkham/followers","following_url":"https://api.github.com/users/jakirkham/following{/other_user}","gists_url":"https://api.github.com/users/jakirkham/gists{/gist_id}","starred_url":"https://api.github.com/users/jakirkham/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jakirkham/subscriptions","organizations_url":"https://api.github.com/users/jakirkham/orgs","repos_url":"https://api.github.com/users/jakirkham/repos","events_url":"https://api.github.com/users/jakirkham/events{/privacy}","received_events_url":"https://api.github.com/users/jakirkham/received_events","type":"User","site_admin":false},"created_at":"2016-10-13T15:55:22Z","updated_at":"2016-10-13T15:55:22Z","body":"Given https://github.com/travis-ci/travis-ci/issues/964 was closed should this or it be reopened. We would really love to have this for conda-forge and I think it would be a great help."}}
{"actor":{"display_login":"jakirkham"}}