Switch to GitHub Actions instead of Travis

[mossroy]

We had a few issues with Travis CI in the past (like #573) and GitHub seems to push GitHub Actions to replace it.
We would have to plug GitHub Actions with Sauce Connect, which seems to be possible (see https://www.linkedin.com/pulse/getting-started-github-actions-webdriverio-sauce-labs-moataz-nabil)

[Jaifroid]

There's an interesting, detailed blog post from the author of Zettlr (an electron-based open source markdown word processor I use) on how he implemented Continuous Deployment with GitHub actions. I found it useful to understand how actions work, though it still seems like a mammoth task. I know we don't have much deployment to do (it might be more useful in Kiwix JS Windows where there are several manual steps I have to repeat to deploy a release), but I think the principles apply to Continuous Integration as well.

[mossroy]

Creating a tag on github does not seem to trigger a build on Travis any more.
So I have to manually run ./create_all_packages.sh -t -v 2.8.0 (for example) after each release (in scripts directory).

[Krinkle]

@Krinkle wrote at #675:

[…] Clunky workaround! (This is one reason we want to move to GitHub actions when we have time to sort that out - #590 ).

Sorry if this is obvious, but as I understand it the tests fail for PRs from non-maintainers because the SauceLabs credentials are meant to be secret. If Travis exposed them to PRs, then anyone could submit a PR that just prints the secret to the build output. GitHub Actions or any other CI service should behave the same way. If it doesn't and it does expose it, and if that's what we want, then we shouldn't mark them as secrets but rather set them as public env variables. I would expect the same to happen for GitHub Actions.

---

I personally favour Travis a bit, as it helps the test setup to be based on open protocols and not vendor locked into this propietary Microsoft platform. Travis isn't fully open-source, but much of it is, and we could of course switch to other service providers in the future (e.g. Circle CI), or other Git hosts (e.g. GitLab).

---

It is of course possible that there are (or were) limitations with Travis that affect Kiwix. I only know that the specific issue of repo secrets and SauceLabs, as far as I know, is an intententional limitation that Travis and GitHub Actions both follow the same way 🙂

@kelson42 Could you confirm or elaborate on what the limitation(s) are that you ran into with Travis? Perhaps there's something I could help with. I suspect it might be a misunderstanding, but happy to be wrong!

[Jaifroid]

For the record, this was @kelson42's advice:

@mossroy @jaiffroid We are moving our CI to github actions for better UX, faster CI and more supported platforms. Most of our repos have it done and devs are happy about it. Would you consider to do that move as well? This might help to fix that ticket!

#573 (comment)

However, devs at Kiwix completely understand the importance of not putting all our eggs in the MS basket...! (It's worth adding that none of us have time to make this switch in any case...)

[Krinkle]

Thanks, consistency is also a good reason!

As for more supported platforms, I do note that Travis seems to have the same platforms (Linux, macOS, Windows), including at multiple versions of those, and (for Linux) multiple CPU archs. We use all of these over at qunitjs/.travis.yml and, so far, no complaints.

Again, I don't know all the context here, so there may be other things we need that are missing :)

[kelson42]

@kelson42 Could you confirm or elaborate on what the limitation(s) are that you ran into with Travis? Perhaps there's something I could help with. I suspect it might be a misunderstanding, but happy to be wrong!

Travis is a good tool but suffers of:

• Relative slowness and instability
• Does not provide (at least it was the case) all the VMs we need in general for the openzim/kiwix orgs
• Has more limitation in terme of resources
• Is less integrated from a UI POV

For all these reasons we have decided to move to Github Actions as an organization. In an attempt to keep things efficient/consistant this would be better to do that here as well.

[kelson42]

Any reason why we keep this ticket open?

[Jaifroid]

@kelson42 Because we have only done Continuous Integration, but we have not yet done UI tests and QUnit tests for PRs. So this issue is only partially completed.

[Jaifroid]

I think this issue is completed now.