[CI] Github Action for lint, build and tests

[yparitcher]

There is a job for linters, a matrix for the emulator builds, and a matrix for cross compile

Fix macos build based on koreader/koreader#8525

Android Builds have not be implemented yet. (I still have to figure out what the toolchain requirements are vs what GHA provides)

This still has some work to be done to deduplicate the dependency install scripts with front and virdevenv
Requires: koreader/virdevenv#71

---

This change is 

[poire-z]

(I unfortunately can't comment on CI/build stuff, this all looks like LTR Hebrew to me :)

[yparitcher]

Ready for merge

[Frenzie]

NB I stupidly just merged this because it all looks fine and I didn't have time to look at it or think about it all week but this is essentially reverting to the pre-Docker days, which is imo not particularly desirable and also unnecessary in base because there are no mysterious segfaults in Docker.

[Frenzie]

That is to say, it's nice as an experiment but I'm not fond of this approach because it triples my workload again. I'd rather just have the CircleCI in GHA. Keep in mind these are not outdated. That's unique to front.

[Frenzie]

PS But also thanks a lot for looking into this stuff! It's just not here that anything is problematic. ^_^

[yparitcher]

PS But also thanks a lot for looking into this stuff! It's just not here that anything is problematic. ^_^

Phew :) I was getting a little worried you were totally against GHA. I had assumed that the CI in base was also giving issues.

Btw, if there is any interest now that all the pieces are in place (toolchains etc) it should not be so hard to make a gha to build a nightly on each commit to master (or every day) and/or to automatically build a release when a new git tag is made.

[Frenzie]

I was getting a little worried you were totally against GHA.

I'm certainly not in favor of it. The only reason we want GHA is because CircleCI has developed annoying authorization-related issues when it should just run on every PR. GHA's horribly convoluted yet straitjacketed "actions" are atrociously complex compared to Travis CI, CircleCI and GitLab CI, among others. Simple things are made very, very hard. It's theoretically available if you parse some JSON API thing buried fifty million documentation pages away, when in Travis CI you could set up the same thing in like 5 minutes.

CircleCI is only an issue on the repo which requires authorization in the first place. I.e., if you want to remove the docs & translations from the CI then GHA is absolutely not necessary and I'd miss it like a toothache; not using secrets would fix CircleCI. Doing that was always my plan B.

I had assumed that the CI in base was also giving issues.

No, the abandoned PR in front would've never happened if these hadn't gone through as expected. See #1375

That was base first to work out the kinks, then GitLab CI nightlies, then front. Except front suddenly suffered from mysterious segfaults that didn't happen with the Ubuntu 16.04 images.

Btw, if there is any interest now that all the pieces are in place (toolchains etc) it should not be so hard to make a gha to build a nightly on each commit to master (or every day) and/or to automatically build a release when a new git tag is made.

Each commit seems rather excessive. Building a new release every day and/or on a git tag could be interesting.

[yparitcher]

GHA's horribly convoluted yet straitjacketed "actions" are atrociously complex compared to Travis CI, CircleCI and GitLab CI, among others. Simple things are made very, very hard. It's theoretically available if you parse some JSON API thing buried fifty million documentation pages away, when in Travis CI you could set up the same thing in like 5 minutes.

:) very true.

I was annoyed by CircleCi refusal to allow be to se what went wrong withoug giving them access to my github account. However since the CirclCI check intergration was added we can now see all that info without logging in.

I.e., if you want to remove the docs & translations from the CI then GHA is absolutely not necessary and I'd miss it like a toothache; not using secrets would fix CircleCI. Doing that was always my plan B.

I might be able to make a separate gha that runs on master that triggers docs and translations, and the rest can be left to CircleCI

[Frenzie]

I have no particular attachment to CircleCI to be clear. I like the setup you proposed in front very well since unfortunately we'd have to do with the same thing in CircleCI anyway.

[Frenzie]

I suspect we'd also have to do the same thing in GitLab CI, since it can't be a coincidence that CircleCI and GHA both show the same weird segfaults problem that I can't reproduce with my local Docker.

[Frenzie]

But anyway, the primary issue with CircleCI is the way authorization works with regard to secrets as well as to show the output.[1] The segfaults are easily avoided, even though I don't really want to avoid Docker. :-)

[1] That's new as well. If I'm not mistaken it always used to show it to you regardless if you were logged in.