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.
Le sam. 17 oct. 2020 à 19:58, Larry Hastings <email@example.com> 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!
> On 10/16/20 1:41 AM, Victor Stinner wrote:
> 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.
> python-committers mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to email@example.com
> Message archived at https://firstname.lastname@example.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 -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/ACT5QH6UYL2F2MFMTRZKBYDKU5SLZ6JA/
Code of Conduct: https://www.python.org/psf/codeofconduct/