Use GitHub actions as a CI instead of Travis.

[FireMasterK]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

Builds and runs tests using GitHub actions instead of Travis.
This is because of Travis's change to remove their OSS free tier.

Fixes the following issue(s)

• Removes the dependence on Travis.
• Add support for GitHub Actions #4059 - Perhaps, they can be combined into the same action? (post a comment only if run in a pr?)

Due diligence

• I read the contribution guidelines.

[TobiGr]

Looks good to me

[TobiGr]

#4059 - Perhaps, they can be combined into the same action? (post a comment only if run in a pr?)

I thought a little about that and came to the conclusion that creating a comment for every build will create lots of spam. My idea is to put some code into the pull request description which is edited once GitHub Actions builds an APK.

### Debug APK
<!-- DO NOT MODIFY the lines below!! GitHub Action will add a link to the latest debug APK once the PR is built. This link will be updated automatically. -->
<!-- github-actions-bot-apk-start -->
APK not yet build | [debug APK @ COMMIT](link to artifact) | latest build failed! This is the last APK: [debug APK @ COMMIT](link to artifact)
<!-- github-actions-bot-apk-end -->

[B0pol]

What about comment once, edit then?

[TobiGr]

@B0pol In this case, we should make sure to place a "Thank you for the pull request! Your changes are being build and a test APK is going to be linked in this comment once all checks passed" comment immediately after the PR is created to ensure people do not need to search for the APK comment.

[FireMasterK]

Won't GitHub hide the comment on large threads? Perhaps we can link the comment in the original comment?

[opusforlife2]

@FireMasterK Github doesn't hide the first few comments, so if it's the second comment it will always remain visible. See 2907 and 3205.

[TheAssassin]

Since I've spent a lot of time with GitHub actions recently, I wrote some tooling around it, e.g., pyuploadtool, which uploads binaries to GitHub releases (in a rolling tag called continuous). I think pyuploadtool's code is the perfect base for writing another tool which comments on PRs with a link to the build artifact. I'll check it out later this day.

[TheAssassin]

Fetching those artifact URLs is quite hard. They only work when you're logged in and have a token. I've managed to get hands on them, but I am not sure it's worth the effort.

Perhaps build artifacts should be uploaded somewhere else, outside GitHub? I don't like how they force a login just to allow people to download a build artifact. It makes no sense, really.

[FireMasterK]

That is true. Where would you suggest them to be uploaded to?

[TheAssassin]

I'm tempted to say "self-hosting"... but I don't really want to put all this on any of my servers.

Edit: just had an idea: we could upload them as an attachment here when creating a comment.

[FireMasterK]

I was tempted to say IPFS :P but yes, I think uploading them via a comment would be a viable solution.

[TheAssassin]

Remember there is no cloud, it's just someone else's computer. I think building trust on binaries thrown onto some random IPFS servers would be more difficult than renting a cheap storage VPS somewhere.

[TheAssassin]

we could upload them as an attachment here when creating a comment.

Doesn't work, the API doesn't provide any endpoint for this. So, it looks like external hosting is necessary. Suggestions welcome.

[FireMasterK]

Remember there is no cloud, it's just someone else's computer.

Your gateway should be on the cloud... And that's the biggest attack vector

I think building trust on binaries thrown onto some random IPFS servers

IPFS requires you to host your own server, you can't just upload stuff to other IPFS nodes...
Other peers can just help host the content, it is cryptographically matched when getting/downloading.

I think ipfs is a good alternative we can experiment with (p2p, saves bandwidth, fast, etc)

But if anyone else has any better ideas, do share them!

[FireMasterK]

There are some ipfs pinning services like pinata/infura if we don't want to self host a node...

[XiangRongLin]

Just a heads up that travis-ci.org will be shutting down on 31st of december. https://docs.travis-ci.com/user/migrate/open-source-repository-migration#q-when-will-the-migration-from-travis-ciorg-to-travis-cicom-be-completed

So a minimal working solution with github actions should be made before then and some buffer to test it in parallel

[TheAssassin]

@XiangRongLin we're aware of this, it's the reason we're working on this PR. We still got more than 2 weeks of time. We'll find a solution.

[TobiGr]

@TheAssassin: I suggest to merge this PR now. It is a replacement for Travis currently. We can add additional features and tweaks later. Travis.org queues our builds causing them to be built up to 7 hours delayed.

[TheAssassin]

I agree. We can always improve it.

[B0pol]

We should remove Travis badge in readme

[TobiGr]

Is it possible to skip the build process for PRs when there is a build for the same commit, because the changes were pushed to this repository? When pushing commits, two builds are run:

[TheAssassin]

Travis did the same, @TobiGr. I assume the "pull request" build tests the merged result, whereas the "commit" build tests the branch as-is. This is likely a bug, not a feature.

[FireMasterK]

Yes, it is possible, we can make it run the builds on push only on the dev/master branch, which would fix this.

Anyways, I don't think this is a huge problem as GitHub allows you to run 20 actions simultaneously.

[TheAssassin]

Plus these actions just run for 4 minutes, which is really not a long time. I have actions which run for an hour, as they do some QEMU-emulated compiling for ARM.