Migrate from travis-ci.org to travis-ci.com #14499
Comments
|
Just a reminder that you'd need to change the "required checks" for protected branches after migration. |
|
Yep. There are also details about cron jobs that I'll take care of. |
|
I will do this now, one day earlier than planned, to give a few more days to clean up the mess if I break stuff. |
|
The most recent PR is now #14600, any PRs created after then but before the transition is complete need to be inspected so they're not blocked on checks that will never run. |
|
The app is now installed org-wide instead of just for wpt.fyi. Following the documentation in https://docs.travis-ci.com/user/open-source-repository-migration/ to migrate each individual repo. |
|
#13352 has finished running on travis-ci.com, and I sent #14603 to test the full set of tests. I've changed the required check from "continuous-integration/travis-ci" to "Travis CI - Pull Request", but unfortunately that makes it show up as required on all existing PRs as well. #14600 is an example of this, now in the state "Required statuses must pass before merging". I'll see if there's a way to trigger the runs without closing and reopening all PRs. |
|
For master, https://github.com/web-platform-tests/wpt/runs/42781561 was the first job to run after the change, followed by https://github.com/web-platform-tests/wpt/runs/42784876. The worked as intended: |
|
https://github.com/web-platform-tests/wpt/pull/14603/checks?check_run_id=42779464 shows what the new checks will look like. Closing that test PR now. |
|
There doesn't appear to be anything in https://octokit.github.io/rest.js/#api-Checks to trigger just Travis checks for a PR. Still looking for a way to resolve #14499 (comment). |
|
Per https://travis-ci.community/t/trigger-build-on-pr-via-api/825/2 it doesn't look like there's a way with the Travis API either. |
|
With no good solution in sight, I've written a script to find the PRs most affected, namely those that had passing old Travis status and now are blocked only missing new Travis check. I'm rebasing where trivial. Going further back in history lots of PRs are also blocked on missing Taskcluster and the like, and those I don't think it makes sense to touch now. |
|
The migration is now complete for all repos in the org, but the remaining work is to make sure that nobody is confused by their PRs being blocked. |
Script that I wrote to find PRs that are blocked on a missing "Travis CI - Pull Request" check'use strict';
const octokit = require('@octokit/rest')();
// https://github.com/octokit/rest.js/#pagination
function paginate(method, parameters) {
const options = method.endpoint.merge(parameters);
return octokit.paginate(options);
}
function getChecksForRef(ref) {
// no pagination because of https://github.com/octokit/rest.js/issues/1161
return octokit.checks.listForRef({
owner: 'web-platform-tests',
repo: 'wpt',
ref,
per_page: 100,
}).then(r => r.data.check_runs);
}
async function getStatusesForRef(ref) {
const statuses = await paginate(octokit.repos.listStatusesForRef, {
owner: 'web-platform-tests',
repo: 'wpt',
ref,
per_page: 100,
});
// Statuses are in reverse chronological order, so filter out all but the
// first for each unique context string.
const seenContexts = new Set;
return statuses.filter(status => {
const context = status.context;
if (seenContexts.has(context)) {
return false;
}
seenContexts.add(context);
return true;
});
}
async function checkPRs() {
const prs = await paginate(octokit.pulls.list, {
owner: 'web-platform-tests',
repo: 'wpt',
state: 'open',
sort: 'updated',
direction: 'desc',
per_page: 100,
});
console.log(`Found ${prs.length} open PRs`);
for (const pr of prs) {
const commits = (await octokit.pulls.listCommits({
owner: 'web-platform-tests',
repo: 'wpt',
number: pr.number,
per_page: 100,
})).data;
if (commits.length >= 100) {
console.log(`Too many commits: ${pr.html_url}`);
continue;
}
// only look at the final commit
const commit = commits[commits.length - 1];
const checks = await getChecksForRef(commit.sha);
const travisCheck = checks.find(c => c.name === 'Travis CI - Pull Request');
if (travisCheck) {
continue;
}
const statuses = await getStatusesForRef(commit.sha);
const travisStatus = statuses.find(s => s.context === 'continuous-integration/travis-ci/pr');
const tcStatus = statuses.find(s => s.context === 'Taskcluster (pull_request)');
if (travisStatus && tcStatus) {
// the `mergeable` state isn't included in the PR list, so fetch it again.
const mergeable = (await octokit.pulls.get({
owner: 'web-platform-tests',
repo: 'wpt',
number: pr.number,
})).data.mergeable;
if (mergeable === false) {
console.log(`Merge conflicts: ${pr.html_url}`);
} else if (travisStatus.state === 'success') {
// High prio: had passing Travis status check
console.log(`Passing on travis-ci.org: ${pr.html_url}`);
} else {
console.log(`Failing on travis-ci.org: ${pr.html_url}`);
}
} else {
// These PRs are so old that they aren't worth poking.
//console.log(`Missing Travis or Taskcluster status: ${pr.html_url}`);
}
}
}
async function main() {
octokit.authenticate({
type: 'token',
token: process.env.GH_TOKEN
});
await checkPRs();
}
main();It only lists PRs that have both an old travis-ci.org status and a Taskcluster status, since PRs predating Taskcluster were already blocked. I went through the list until I got to PRs that haven't been updated in the past two weeks. |
|
I am not going to poke more PRs manually, but I'll list the output of the script now, so that they all get backlinks here to help understand the problem: Found 468 open PRs |
|
Alright, with that I declare the migration complete! |
|
Everyone, if you find your way here trying to find out why your PR is blocked on Travis, either make some change (e.g. rebase) to your branch and push it again, or just close and reopen the PR. If you still can't get Travis to run+pass, please let me know. |
|
For lack of a better place, I'll explain an oddity that's happened here. After I discussed the trouble we had with the changed check name with Travis support, they enabled an internal setting on our repo to send both statuses and checks. That caused PRs to have two Travis entries, one "Travis CI - Pull Request" (check) and one "continuous-integration/travis-ci/pr" (status). This was the case over the holiday. I asked Travis to undo it yesterday, and #14766 is the last PR which got both. |
We now have the ability to migrate individual repos in the web-platform-tests org from travis-ci.org to travis-ci.com, and we have already migrated wpt.fyi as a trial. Old links and build history are preserved.
There isn't a strong reason to migrate now, but we eventually have to. One upside is that we get the new Checks API integration which is also what Azure Pipelines uses. The Travis integration isn't very fancy, but it's a small improvement. Example from wpt.fyi:
https://github.com/web-platform-tests/wpt.fyi/pull/910/checks?check_run_id=40636708
@web-platform-tests/admins I would like to do this migration org-wide. If I do not hear concerns within a week I'll go ahead.
The text was updated successfully, but these errors were encountered: