Sometimes, when you reschedule a build in Travis CI, a PR gets *two* Travis CI jobs instead of one, and the first one remains stale forever. There are multiple issues with Travis CI.
Victor Le sam. 17 oct. 2020 à 19:58, Larry Hastings <la...@hastings.org> a écrit : > > > > I don't know how the configuration on this stuff works. But my dim > understanding is: some automation from Github (that we own / configure / > wrote) notices that we have a new checkin on a PR and kicks off the Travis CI > build. The problem is that sometimes the status of the Travis CI build > doesn't get reported back. > > It seems to me that this is a race condition. You don't usually lose the > race, and so usually everything is fine. But it's super frustrating on the > rare occasion when you do lose the race, because you're stuck. You can't do > anything to fix it. > > But that itself suggests the solution--when a user loses the race, let the > user retry. If we simply had a "restart Travis CI job" button somewhere, I > think that'd be a good-enough "Band-Aid" over the problem that we could live > with it for a long long time. Long enough maybe for someone to fix the bug! > Or for someone to replace Travis CI with something less race-condition-y! > > > /arry > > On 10/16/20 1:41 AM, Victor Stinner wrote: > > Hi, > > Python has no mandatory Linux CI job on pull requests anymore. Right > now Windows (x64) remains the only mandatory job. Please be careful to > manually check other CI before merging a PR. > > -- > > We had to deal with at least 3 different issues on the Travis CI over > the last 6 months. The latest one (3rd issue) is on the Travis CI side > and is known for months. Sometimes, a Travis CI build completes but > the GitHub pull request is never updated. Since Travis CI was > mandatory, it was never possible to merge some pull requests. I also > noticed a 4th bug, sometimes a PR gets *two* Travis CI jobs on a PR > for the same Travis CI build, only one is updated, and so again, the > PR cannot be merged. > > For all these reasons, Travis CI was made optional. > > I would be nice to have a mandatory Linux job: "Tests / Ubuntu > (pull_request)" is a good candidate. But I didn't check if it's > reliable or not. > > See https://github.com/python/core-workflow/issues/377 for the discussion. > > Note: if someone manages to fix all Travis CI issues, we can > reconsider making it mandatory again. But it seems like most people > who tried (included me) are tired or bored by Travis CI. > > Victor > > > _______________________________________________ > python-committers mailing list -- python-committers@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committers@python.org/message/QTAXIPIBIURBYMALYSKMMNVUOT7IBGPU/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-le...@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/ACT5QH6UYL2F2MFMTRZKBYDKU5SLZ6JA/ Code of Conduct: https://www.python.org/psf/codeofconduct/
