Swap the CI to GitHub Actions from Travis

[tannewt]

Here is a normal test build: https://github.com/tannewt/circuitpython/runs/205207009

It failed on S3 upload because my repo doesn't have the secret set.

The release uploads are working but got rate limited: https://github.com/tannewt/circuitpython/runs/205075094 Theoretically we can squeeze under the 1,000 request limit of the repo token with a single release but we may need to use a separate token if not.

[sommersoft]

Looks like an excellent jump-off to me!

Its been hard to concentrate on a review, without my mind wandering off into "what if..." scenarios. Thanks for this. 👏

[sommersoft]

I have a couple thoughts, but I don't think they warrant holding this up:

• Break the workflow and actions into separate files. Scrolling down through 72 builds is cumbersome. And while all of the builds are technically ARM, grouping them by chipset (like the ports directory does), might be more intuitive. It wouldn't necessarily require duplicated code all over the place, if I'm reading the docs correctly. The meat of the build can be placed into a .github/actions/build_board.yml, and called from the workflows. P.S. I love the return of the build output; I've missed the flash/RAM stats

• For the release uploads, would adding rate-limit handling to post in adabot (like get has) work? I can't find any info on idle timeouts (but haven't looked too hard). At the current rate, pretty sure we'll be above 1000 earlier than most of us think. (🤞)

[dhalbert]

This looks good to me but I have no comments about the details.

In terms of rate limiting, can we avoid triggering it by doing our own rate limiting by delaying between requests?

[tannewt]

I have a couple thoughts, but I don't think they warrant holding this up:

* Break the workflow and actions into separate files. Scrolling down through 72 builds is cumbersome. And while all of the builds are technically ARM, grouping them by chipset (like the ports directory does), might be more intuitive. It wouldn't necessarily require duplicated code all over the place, if I'm reading the docs correctly. The meat of the build can be placed into a `.github/actions/build_board.yml`, and called from the workflows. _P.S. I love the return of the build output; I've missed the flash/RAM stats_

I don't think we can get away from the 72 build thing. Making it workflow will just lead to 72 workflows. I'm not sure about the cross-referencing. Would be good for you to try. ;-)

* For the release uploads, would adding rate-limit handling to `post` in adabot (like `get` has) work? I can't find any info on idle timeouts (but haven't looked too hard). At the current rate, pretty sure we'll be above 1000 earlier than most of us think. (🤞)

Ya, we could but then the build will take longer. I'd rather just give it a normal api key with 4,000 limit per hour.

[ladyada]

yayyyy