Travis CI doesn't report its status or doesn't run on Python pull requests #371
Comments
|
Another example: python/cpython#20797 got a new commit longer than 30 minutes ago, but Travis CI still says " continuous-integration/travis-ci Expected — Waiting for status to be reported" with no link to a build. ... but again, a few minutes later, all become green and I was able to merge the PR. I don't know. It's just that I'm used to very reactive Travis CI. Maybe GitHub or Travis CI are just a little bit slower these days :-) |
|
TravisCI is third party app that we don't manage. Don't think there is much we can do here. Perhaps best to file the issue with TravisCI. |
|
So what is the purpose of this issue? Is it to ask if we should move the coverage report off of Travis? Otherwise the title isn't helpful since we don't control Travis nor have any connections there so we can't do anything about it misbehaving short of (yet again) not making it required. |
|
The purpose of this issue is to collect the issues that I saw with Travis CI. But sorry, the status is unclear. Sometimes, it seems like Travis CI is broken, but a few minutes later, it's back to life. |
|
In clear, right now, I don't ask to do anything :-) |
|
Ok, here is a more concrete proposal: "Don't run Python and C coverage jobs of Travis CI on pull requests" https://bugs.python.org/issue40993 Extract:
|
|
Screenshot of the "status not reported" issue:
The Travis CI has no "details" link. |
GitHub doesn't give the link to the Travis CI build, whereas the build was already created: Maybe there is just a long delay on notifications from Travis CI to GitHub sometimes. |
|
I just ran into a similar issue on python/buildmaster-config#204; Travis ran and passed, but never reported back to GitHub. |
|
That's probably on Travis' side as the GitHub API for status checks takes the URL in as part of the status check, so either GitHub is dropping an API call on the floor (which is not something I have really come across), or Travis has a bug where they are not sending an update. |
|
Recent failure: python/cpython#21594 (comment) |
|
Does someone know how to report issues to Travis CI? |
|
@vstinner nope. I believe we lost our connection there after their big round of layoffs after being acquired. |
|
@ewdurbin or @Mariatta: Would you mind to check the Travis CI integration in GitHub? See checks in: https://travis-ci.community/t/known-issue-travis-ci-reports-expected-waiting-for-status-to-be-reported-on-the-github-status-api-but-the-status-never-arrives/1154 |
Travis CI issues should now be reported to https://travis-ci.community/. I will wait until these checks are done before reporting the issue. |
|
It does not appear that Travis CI is integrated via the Travis CI GitHub Application and I do not see a way to initiate that. All of the python org repositories are still using the Legacy Integration, and the steps to migrate have never been clear. |
|
The linked documentation is for travis-ci.com... I don't see a mention of travis-ci.org where all of our repositories are currently configured. |
It seems like travis-ci.org is the "legacy Travis CI" and all projects should migrate to travis-ci.com: https://devops.stackexchange.com/questions/1201/whats-the-difference-between-travis-ci-org-and-travis-ci-com At https://travis-ci.org/account/repositories, I read: Legacy Services Integration. Migration is explained at: https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com/#existing-open-source-repositories-on-travis-ciorg The surprising part is that the migration to travis-ci.com started in May 2018, but the migration procedure still mentions "beta testing"! I requested to enter the beta test with my personal account to see what's going on.
https://travis-ci.com/account/repositories (.com link) now lists repositories using: GitHub Apps Integration. |
|
Hum, for https://travis-ci.com/github/vstinner/python-ptrace I had to click on [Migrate] button to migrate a single project. The migration doesn't seem to be fully automated. |
|
Migrating an organization is more tricky:
Each project must be migrated manually by clicking on a [Migrate] button. Migrating an organization has no effect immediately on project, if I understood correctly. When a project is migrated, the nice thing is that the build history is migrated as well. If you want to start on a small project, you can begin with https://github.com/psf/pyperf/ which I co-maintain. |
|
FYI I'm dropping off this issue as at this point I think we should drop Travis (and Azure Pipelines) for GitHub Actions so we only have to worry about one CI system failing instead of 3 😉 . |
GH Action was broken today, I just fixed it: python/cpython#21806 It was nice to have Azure as a "fallback" to continue testing Windows (it detected some issues), and Travis CI as a "fallback" to continue testing Linux. In a perfect world, all CIs would be trivial to maintain, we would have a great feedback on reporting CI issues, and CI would be super reliable. In practice, each CI has its own set of issues that we have to deal with, and we usually have to wait a few days up to a few months until CI issues are fixed :-( For some CI issues, I would need access to the admin page of GitHub projects, but only a few people have this account, and so fixing CI issues doesn't scale well. Honestly, I'm not sure how to enhance the situation. But I'm fine with the current way of handling issues: "best effort" and be patient :-) |
|
@vstinner That's great that you have the time, but what I'm saying is I don't have the time to participate in trying to keep 3 CI systems running. I'm happy to help out with GitHub Actions, but I am personally opting out of discussions and helping with Travis and Azure Pipelines. |
|
It seems like someone (@ewdurbin ?) migrated https://travis-ci.org/github/python/cpython (ORG) to https://travis-ci.com/github/python/cpython (COM) : that's great! Sadly, I had to close/reopen my PR python/cpython#21924 since hours later, "continuous-integration/travis-ci" job was still at "Expected — Waiting for status to be reported" (no link to the current/completed Travis CI job). I closed/reopened my PR for the 2nd time and I checked: Travis CI triggered https://travis-ci.com/github/python/cpython/builds/180642803 job and the job completed successfully. I refresh my python/cpython#21924 tab and tada! This time it worked! So it's not fully repaired :-( I'm disappointed, I expected the issue to be fixed just by migrating the GitHub cpython project to travis-ci.com :-( Anyway, I managed to workaround my issue. I was able to merge my PR, so it's not really a "blocker issue". It's just a little annoying when it happens. |
|
Oh wait. In fact, the 3.8 branch has two jobs:
Is it possible that the 3.8 branch has an outdated Travis CI configuration? I don't know if it's something from the .travis.yml file or something in the GitHub admin page of the project. |
|
I checked a recent merged PR in the master branch: python/cpython#21907 (3 days ago) It only has a single Travis CI job: "continuous-integration/travis-ci/pr The Travis CI build passed". This one seems to be the legacy API. When was the cpython project migrated to travis-ci.com (new GitHub Action API)? |
|
On a more recent PR on the master branch, python/cpython#21925, there is a single Travis CI job: new GitHub action API. |
|
Oh ok, I worked around by re-creating a new PR with the same changes. It seems like my old PR got an old Travis CI job since it was created before cpython moved to travis-ci.com. New PRs only get a single Travis CI: the new one using GitHub Action. Maybe some PRs will be stuck by this migration and may have to be recreated. Closing/reopening a PR doesn't work around the issue this time :-( While a few PRs will be affected, I hope that the new Travis CI job will be more reliable! |
|
The migration occurred on Monday. Pushing a new commit to the underlying branch of a given PR should be sufficient to get the necessary build. @mustafa-travisci do you have any guidance on how to handle open Pull Requests that have the .org status, though now we are requiring the new status for branch protection? |
|
Since all Travis CI GitHub statuses(.org)/checks(.com) are per commit you may need to add a dummy commit for an open PR branch to Travis CI check to be passed and merged. Do you think this would work for your cases as well? This way you won't need to recreate existing open PR. Thanks. |
|
PRs created before the migration should keep their existing Travis CI result (pass or fail). If a PR is updated (new commit, rebased), Travis should be updated automaticalled from .org to .com. I'm not sure what I had issues in my specific PR. So far, I didn't hear any complain, the migration seems to work well. |
|
Finally, I close this issue. If there are new problems with Travis CI, please open a new issue. Hi, During the last 3 months, the Travis CI job failed randomly to report the build status to GitHub pull requests: I discovered that travis-ci.org uses the legacy GitHub API, whereas there is a new travis-ci.com website which uses the new GitHub Action API. The migration started in May 2018, is still in the beta phase, and must be done manually:
Two weeks ago, Ernest W. Durbin III migrated the GitHub "python" organization from travis-ci.org to travis-ci.com, and also migrated the cpython project to travis-ci.com (the migration requires to migrate each project individually). Since the migration, I didn't notice the "Travis CI doesn't report the build status" issue anymore on new pull requests. Great! Thanks Ernest! VictorNight gathers, and now my watch begins. It shall not end until my death. |
Example: python/cpython#20807 has "continuous-integration/travis-ci Expected — Waiting for status to be reported [Required]" but no link to a Travis CI job. Since the job is required, I cannot merge this PR.
https://travis-ci.org/github/python/cpython/builds shows that the latest build ran 11 hours ago.
The current https://travis-ci.org/github/python/cpython is running for 4 minutes: tests on "Pull Request #20768 bpo-40939: Remove the old parser".
... but while I was writing this issue, python/cpython#20807 got a green "Travis CI": https://travis-ci.org/github/python/cpython/builds/697264594 passed (but the two coverage jobs are still running). So now I'm confused.
Maybe the fix is just to wait a bit :-) I closed/reopened python/cpython#20807 23 minutes ago to force to re-run Travis CI.
I also noticed Travis CI preventing to merge a PR beause the "coverage (C)" job was still running, whereas the other required Travis CI jobs passed successfully. Example: python/cpython#20767 shows that Travis CI is still running, whereas https://travis-ci.org/github/python/cpython/builds/696949107 completed but "Test code coverage (C)" job failed with "The job exceeded the maximum time limit for jobs, and has been terminated.". The last line is "0:46:18 load avg: 5.32 [254/426/1] test_profile passed -- running: test_tokenize (8 min 55 sec), test_multiprocessing_spawn (2 min 36 sec), test_statistics (1 min 53 sec)". Longer than 46 minutes to run the test suite is quite long :-(
Maybe we should just remove the coverage jobs on Travis CI, unless someone actually uses them? See https://bugs.python.org/issue40237
The text was updated successfully, but these errors were encountered: