!! Temporary PR freeze until we have CI !!

[lchladek]

Edit (Mikołaj): Original title: Migrate GitLab CI/CD to GitHub Actions. Title changed because we can't really merge anything until we have a working verification step of some kind.

What needs to be done to move to GitHub CI:

• [x] Migrate the gitlab-ci.yml build script to GitLab Actions
  • [x] Build
  • [x] Tests, lints
  • [x] Documentation
• [ ] Integrate test coverage + other metrics in GitHub
• [ ] Make GitHub Pages for documentation
• [ ] Add GitHub releases for the installer

Since GitHub Actions appears to bill the repository owner for CI on private repositories, we first need to make sure that this migration is the way to go. It may be necessary to wait until the repo is public, at which point there is a usage quota (see link). Before I go ahead and implement the Actions, we therefore need to decide:

• [x] Is GitHub Actions the way to go?
• [x] Should we wait until the repo is public?
• [x] To save costs/quota, how much CI do we really need?
  • [x] Build, testing, linting
  • [x] Releases
    • [x] Linux + DelftBlue
    • [x] macOS
    • [x] Windows
  • [x] Documentation
    • [x] LaTeX
    • [x] GitHub Pages for manpages
    • [x] GitHub Pages for rustdoc

I would appreciate some input on this (@Apanatshka)

[mgazeel]

Can we also adopt the fork of the musl-linux container to the org?

Currently its hosted at https://github.com/mgazeel/muslrust-texlive.

[lchladek]

If you need a different operating system or require a specific hardware configuration, you can host your own runners. For more information about self-hosted runners, see "Hosting your own runners."

From Understanding GitHub Actions

I will look into this.

[mgazeel]

Self hosting runners is waaay overkill, and we still need docker containers anyways.

[lchladek]

Can we also adopt the fork of the musl-linux container to the org?

Self hosting runners is waaay overkill, and we still need docker containers anyways.

GitHub Actions doesn't use docker containers. To do this, it appears that you have to set up docker within one of their Ubuntu runners. As mentioned, I will look into if this is the easiest way to set up a musl release.

[mgazeel]

Okey thats problematic and not nice, we stick to ubuntu then.

[mgazeel]

I'll write up the yaml in a sec

[lchladek]

I'm ok with doing this, suggest you look at #2 instead and figure out what happened to 1.0.2. Also, we should definitely wait for @Apanatshka to check in before actually spawning CI jobs, as mentioned in the issue!

[mgazeel]

1.0.2 is fine, the MR of course didn't migrate, there is a PR for it now (#4).

Since this requires basically rewriting the pipeline, I'm willing to write the base for this and let you expand on it with any metrics you want.

[lchladek]

Just reassign it to yourself then.

[mgazeel]

Should we do windows releases? now that we have a runner for it?

[andtsa]

I think yes, a lot of the users will likely be on windows

[andtsa]

for major versions we can have tags with binaries for all Macos windows linux

[Apanatshka]

Yes, I think GitHub Actions is the way to go, but indeed wait with spawning them until the repo is public so we don't incur costs for it. I can check with @EmirDe next week if we want to pay for a limited amount of CI before we open up the repo to the rest of the world. Ideally we can stay within the free usage quota for open source projects in the future.

Can you make a cost estimation based on your experience with CI on GitLab?

[lchladek]

I just read over the knowledge base articles again [1] and some users' experiences [2] and it turns out that GitHub Actions is completely free (even Windows, macOS) with no minute quota if the repository is public.

While the repository is private, I estimate the following number of billed minutes for each pipeline task:

• Building, testing, linting = 10 minutes
• Releasing = 32 minutes
  • Building for Linux = 2 minutes
  • Building for Windows = 4 minutes (2x multiplier applies)
  • Building for macOS = 20 minutes (10x multiplier applies)
  • Building documentation = 5 minutes
  • Packaging all of the above = 1 minute

This is with a parallel pipeline optimized for execution speed, not total runtime. By combining jobs and not building multiple times, we can easily cut down the build, test, lint minutes by half.

Now, with the above numbers, a very liberal monthly cost estimate would be:

• 160 pushes x 10 minutes (build, test, lint) = 1600 minutes
• 5 pull requests x 2 attempts at release x 32 minutes (release) = 320 minutes

This fits into the 2000 minutes/month Free plan, assuming that you (the repository owner) are only using them for this project. The estimate is also for a very high amount of activity, and in such a case there is always the option of only running build, test, lint for pull requests rather than for all pushes.

[EmirDe]

I am trilled that we have your support even after the software project! No worries if we go slightly above the CI minutes.

[mgazeel]

If this is confirmed I'm starting work on testing the CI in the repository.

[mgazeel]

I'm happy to announce that the CI is implemented, and ready to review in #7, after merging we can close this and work on the other PRs

[mgazeel]

We also cannot add github pages without making the repository public, that will have to wait

[lchladek]

Neat! I suggest making a new issue for GH Pages (and also OSX/Windows binaries if you don't intend to add that to PR #7)

[lchladek]

Edit: added task to publish coverage Edit edit: already in the checklist, disregard!