Core-workflow: Replace GitHub Services with GitHub Apps

[Mariatta]

In python/cpython we're using Travis CI services (and probably in other repos too).

It can be seen in: https://github.com/python/cpython/settings/installations

There is guide for migrating Travis CI: https://docs.travis-ci.com/user/legacy-services-to-github-apps-migration-guide/ but I don't know about the IRC service.

[brettcannon]

The key thing from what I can tell is that Travis has not migrated any open source projects to travis-ci.com from travis-ci.org and that has to happen first before we can move over to a GitHub App for Travis.

[Mariatta]

Reading this, it says "This is an opt-in process: to have a repository migrated over, it must first be activated on travis-ci.com."
Is it possible to "activate" it first?

[brettcannon]

That's the thing they haven't outlined how to do yet last time I checked.

[Mariatta]

I found the button to "activate" it, by going to https://travis-ci.com/profile/python. But I don't know what the side effect of doing it now, considering we have impending release cutoff.

[brettcannon]

Ah, I ain't clicking that button until 3.7 is out the door. 😄

[webknjaz]

@brettcannon @Mariatta I've accidentally noticed this thread and have some info about Travis CI:

1) It is possible to email Travis CI and ask them to migrate repos
1.1) In this case all build history will be lost since they are still in progress of creating a proper migration system. I mean, it will be still in the .org website until it shuts down.

2) I've migrated all aio-libs repos there and faced some undocumented issues (which we managed to fix in the end)
2.1) All secrets are encrypted using keys from .org instances of repos, so they need to be encrypted again with a new travis project. It doesn't work out of the box, because CLI options --pro and --org do the wrong thing (for various reason). The workaround is to still use --org, but provide .com API endpoint:
bash ORG_NAME={{ YOUR_ORG_NAME }} REPO_NAME={{ YOUR_REPO_NAME }} travis login --api-endpoint 'https://api.travis-ci.com/' travis encrypt -r "aio-libs/${REPO_NAME}" --api-endpoint 'https://api.travis-ci.com/'
2.2) Also, codecov.io integration was broken, because they also assumed .com to paid-only API. They've fixed it after some time. So there might be other services which didn't do necessary changes.

[Mariatta]

Thanks for the update! Good think we did not click that button yet!

It is possible to email Travis CI and ask them to migrate repos

🤔 When we click that green button, will it migrate everything, or only certain repos at a time?

in this case all build history will be lost

I'm curious how it will affect the 700+ open PRs currently? Everything needs to be rebuild?

2.1) All secrets are encrypted using keys from .org instances of repos,

I don't think we use this within cpython. But I don't know about other repos within python org.

2.2) Also, codecov.io integration was broken, because they also assumed .com to paid-only API. They've fixed it after some time. So there might be other services which didn't do necessary changes.

Within python GitHub org, I only have visibility for cpython and miss-islington. Perhaps an org admin/owner (@ewdurbin) can go through all repos that depend on travis CI (service) and tell us what other apps could be affected?

[webknjaz]

:thinking: When we click that green button, will it migrate everything, or only certain repos at a time?

Back when we did migration, there was no button. So I don't know. You may email them. They help a lot with all questions (sometimes not immediately, though). Still, they like when you also participate in troubleshooting.

I'm curious how it will affect the 700+ open PRs currently? Everything needs to be rebuild?

It was around 26 days ago and I've found a PR created before that: https://github.com/aio-libs/aiohttp/pull/2978. It doesn't have Checks API info, so it wasn't re-triggered in the new CI env. Also it still has links to the old .org CI build.
You might need to hit Travis' API to trigger rebuilds, it's better to contact them and ask what they'd recommend (probably restart all PRs gradually). But for new pushes into old PRs Travis builds should start as usual.

Within python GitHub org, I only have visibility for cpython and miss-islington. Perhaps an org admin/owner (@ewdurbin) can go through all repos that depend on travis CI (service) and tell us what other apps could be affected?

Here's a check I made for keeping eye on invalid .travis.yml of all org repos, running in Travis as a cron build on daily basis. You can modify it to get repos with Travis config:
https://github.com/aio-libs/night-watch/blob/master/.travis.yml#L21

[Mariatta]

I wrote to [email protected] 2 days ago with my questions. No reply. :woman_shrugging:

[webknjaz]

Yeah, that happens. Sometimes they are busy with things.
I've emailed them asking to migrate newly transferred repo a few days ago and during the conversation with Travis support realized that there much be some bug: the repo just doesn't show up in .com even after multiple synchronization attempts by @asvetlov. So after intense mail exchange on June 19, there's no reply from them since then.
I think @svenfuchs recently released a new version of conditions, so they might be focused on that now.

[Mariatta]

Answers from travis-ci:

🍝
Question 1: How the migration will affect those repositores (under python organization)?
When you activate the GitHub App for your organization, you'll be redirected to a page in GitHub that will allow you to grant access to Travis CI for specific repositories. In this page, you can choose "all your repositories", or only specific ones:

If you grant access for private repositories of the organization that were already building in travis-ci.com, or for new public repositories that haven't run a build in travis-ci.org yet, these will start building through the new integration right away. This should not cause any changes or disruptions, as the difference is based in how we receive the events from GitHub for your projects and, in general how Travis CI authenticates with GitHub. In the case of new, public repos, this would just be as starting a project from scratch.

On the other hand, if you try granting access to public repositories that exist in travis-ci.org, which I believe is the scenario for the Python org, this will not have any immediate effect. At the moment, it is not possible for users to move their existing travis-ci.org projects to travis-ci.com manually since we're still working on the tool that will allow users to migrate all their data between the two infrastructures. However, we can move your projects from .org to .com upon request if users are okay with losing their build history and/or settings (encrypted env vars included). Otherwise, if losing this information is not an option for you and your team, we can add you to the list of users that would like to be notified when it's possible to move your open source projects to travis-ci.com with all their data.

A more detailed guide on the migration process is available at: https://docs.travis-ci.com/user/open-source-on-travis-ci-com

Question 2: Will we have the option to migrate one repo at a time, for example one of our less active repos.
Yes! The active repositories that are using the old GitHub integration will remain as they are, unless they're activated via GitHub Apps. In that case, those repos would start building with the new system instead.

As a test, I'd recommend activating the new GitHub Apps and only grant access to those repositories, so that you can test how it goes. Also, if you'd prefer granting access to specific repos instead of using the "All repositories" access option in the future, I'd recommend taking a look at this tool we created for migrating the repositories programatically: https://docs.travis-ci.com/user/travis-migrate-to-apps-gem-guide/

(Note that this would only make sense for new public repos, or existing private repos, since those public repos that are currently built in travis-ci.org would appear as "locked" in the UI)

Question 3: Are we going to have to restart travis for all existing open pull requests (700+)?
If a repository is migrated to travis-ci.com, this platform will start receiving the GitHub events. In the case of PRs, what would happen is that the builds triggered from new commits in the PR would start running in travis-ci.com instead of travis-ci.org.

If the PRs have been opening for a while but they don't have any new commit activity, GitHub should still reflect the status of the builds that ran for that PR previously, and PRs should be mergeable if the build was successful. If any of those PRs is old and it got very outdated with the target branch or have conflicts now, the new commits that are pushed to solve that situation would start building in travis-ci.com.

[Mariatta]

I would like to move python/miss-islington to travis-ci.com. It does not have any open pull requests, and I personally don't mind losing the history.

[ewdurbin]

@Mariatta I've installed the new travis-ci.com app for the Python organization, and approved miss-islington.

[Mariatta]

Thanks @ewdurbin !! 🌮

[Mariatta]

Travis CI GitHub App has been enabled.
(I actually forgot about this issue, and opened another thread in discourse)

Not sure what to do about IRC. Quick googling didn't return any result about IRC GitHub App.

[webknjaz]

@Mariatta it should be fairly easy to write an IRC posting thing I think...

P.S. I'm about to make a framework for writing bots with less boilerplate to make it easier and lower the entry barrier for writing such apps.

[Mariatta]

I don't use IRC so I don't even know what it does.

Perhaps bigger question is, how many people still using it? We already have so many other communication channels, is IRC something we still want to keep doing?

[webknjaz]

I wasn't used to be using IRC a lot and thought that it's not used a lot a year ago.
Now, I'm seeing a lot of open source folks use it heavily.

Dunno about Python but it's probably worth checking.

[brettcannon]

Someone should ask on Discourse/Zulip or hop on to IRC in #python-dev and just say that the integration is going away until someone finds a replacement.

[Mariatta]

It seems like @ewdurbin had set up something, but since I don't use IRC myself, I don't know how it works out in the end.
https://discuss.python.org/t/replacement-for-irc-github-service/805/22

[brettcannon]

So then I think we can close this as we have done what we can and if the IRC webhook is broken and someone wants to see it fixed that can be handled as a separate issue.