Transition from TravisCI to GitHub CI #7444
Conversation
Convert the continuous integration process to use GitHub's internal CI cloud. Allows us to run up to 20 jobs in parallel, speeding up CI immensely. Translate all Travis CI configuration into event-driven GH YAML files.
|
I'm 99.9% confident on the PR CI flow, 99% on the tagging, and about 95% on the updating of the separate GH.io repo where the main Arduino JSON lives (worked OK on my own private branch, but it's the part of the CI I'm least familiar with). Runtime is ~6-8 minutes start to finish, with 20 concurrent jobs. Don't know what Azure instance they're running, but it's slightly faster than the Travis ones, but biggest win is due to 4x more parallel jobs. They can also cache the As a first step, this does have some less-than-elegant hacks like preserving the TRAVIS_XXX environment names, just to limit the scope of changes. Once we're migrated, code cleanup like that should be pretty simple. We may also want to think about a different way of keeping the GH SSH keys (store it directly in the GH secrets instead of encrypting a private key w/secrets key and IV). This specific PR will never complete because it's removed the TravisCI control file so the API is going to wait forever for a response from travis-ci.org which will never come, but we can easily force a merge when the time comes. The branch protection will also need updated through the GH site to require the new tests, can be done at the same time as removing Travis integration. Also, as you're reviewing, note that GH CI uses |
The original comments suggested adding a new SSH key to a user account which would have allowed complete access to all repos and all other global user settings. A really bad thing if it got into the wild. Instead, a single deploy key can be added to a single repo. This only grants git push access/etc. for that single repo and not for the entire user account. Update the docs accordingly. Also rename push.yml->pull-request.yml since it runs on a pull request, not a master push.
Add basic, fast TravisCI script to keep the TravisCI jobs alive even if GitHub CI goes down. Belt-and-braces, but it's free. Limit the runs on the Travis jobs to 5 short ones in total to match the runtime of the GitHubCI.
Thanks! I'm checking the deployment stuff on my own repo and will update the JSON repo once that's checked out. |
Testing with my local repo first
earlephilhower
force-pushed
the
toghci
branch
3 times, most recently
from
b581075
to
cbdb0bc
Compare
earlephilhower
force-pushed
the
toghci
branch
3 times, most recently
from
43c8abc
to
a4c7e1a
Compare
Testing now gets the proper release name for package(draft) and release. Go back to the esp8266,github.io repo for release updates.
|
I've tested draft generation and JSON updates in private repos, now. The new deploy keys have also been installed on the JSON repo and secret update in this repo. |
Convert the continuous integration process to use GitHub's internal
CI cloud. Allows us to run up to 20 jobs in parallel, speeding up
CI immensely.
Translate all Travis CI configuration into event-driven GH YAML
files.
We'll need to get the -edit-deploy-edit- key secrets transferred from TravisCI to GH,
but testing with my own key secrets and private repo worked
automatically.
On a pull, the standard CI runs are done.
On a tag push to the master branch of the format
#.#.#...,will generate a draft release and upload the JSON and ZIP.
When a release is published, it will update the GH.io JSON
file used by the Arduino board manager with the latest version.