3 ms·

Gitlab CI is so weird man, depending on where you are workflow/rules and so on seems to have very different effects. The obsession it is has making jobs === VMs

Gitlab CI is so weird man, depending on where you are workflow/rules and so on seems to have very different effects. The obsession it is has making jobs === VMs is also mind bending, why so many virtual machines for one pipeline! You can't consolidate child pipeline reporting up to a higher level - all the data is there in the UI but hidden. There were loads of other things. Github Actions which is largely free (if you use your own runners) is much better.

CameronNemo 3y ago
What do you mean by jobs == VMs? I thought gitlab ci was mostly containers.
- hhh 3y ago
  You choose what you want it to be. https://docs.gitlab.com/runner/executors/ https://docs.gitlab.com/runner/executors/
  - CameronNemo 3y ago
    Sure, but the hosted runners use the docker executor IIRC and container-based executors are quite common.
andrewstuart2 3y ago
Not sure what you're getting at, as I've always found GitLab CI substantially more obvious than actions. CI definitely shouldn't be a snowflake, and it almost certainly shouldn't be something you can't run locally with very similar steps. GitHub makes it nearly impossible to replicate a CI build locally unless you're super familiar with the actions being used and how they were implemented, because actions are highly abstracted from what is actually happening. GitLab CI is just a series of shell commands with a container image for context (bring your own tools). It's usually pretty easy to figure out a GitLab build unless you get fancy with includes or child jobs which imo, for the aforementioned reasons, are substantial antipatterns.
- mathstuf 3y ago
  The other things I really like about GitLab's CI is that it's easy to use different images/machines for different tasks. For example, the build of a CUDA-using job can be done on any hardware, but the testing needs CUDA access. Instead of tying up our CUDA machines on boring compiles, the jobs are split on build/test lines so that the CUDA hardware has a better shot of actually being utilized well. Same thing with giving only testing access to things like X11 setups or whatnot. One can also build once and test multiple ways with this method (e.g., build a ABI3-using Python wheel once and test it with all newer versions of Python with distinct jobs to spread the work and to allow the pipeline to show better things at a glance. I have no idea how to do such "tee" bits in GitHub Actions (though I haven't looked in a while, the artifacts usage seem…convoluted compared to GitLab's "here's a list of globs"). For that matter, "join"s would be nice too (e.g., to collect the 20 or so wheels built across various jobs into one `twine` upload).

CameronNemo 3y ago

What do you mean by jobs == VMs? I thought gitlab ci was mostly containers.

hhh 3y ago
You choose what you want it to be. https://docs.gitlab.com/runner/executors/ https://docs.gitlab.com/runner/executors/
- CameronNemo 3y ago
  Sure, but the hosted runners use the docker executor IIRC and container-based executors are quite common.

andrewstuart2 3y ago

Not sure what you're getting at, as I've always found GitLab CI substantially more obvious than actions. CI definitely shouldn't be a snowflake, and it almost certainly shouldn't be something you can't run locally with very similar steps. GitHub makes it nearly impossible to replicate a CI build locally unless you're super familiar with the actions being used and how they were implemented, because actions are highly abstracted from what is actually happening. GitLab CI is just a series of shell commands with a container image for context (bring your own tools). It's usually pretty easy to figure out a GitLab build unless you get fancy with includes or child jobs which imo, for the aforementioned reasons, are substantial antipatterns.

mathstuf 3y ago
The other things I really like about GitLab's CI is that it's easy to use different images/machines for different tasks. For example, the build of a CUDA-using job can be done on any hardware, but the testing needs CUDA access. Instead of tying up our CUDA machines on boring compiles, the jobs are split on build/test lines so that the CUDA hardware has a better shot of actually being utilized well. Same thing with giving only testing access to things like X11 setups or whatnot. One can also build once and test multiple ways with this method (e.g., build a ABI3-using Python wheel once and test it with all newer versions of Python with distinct jobs to spread the work and to allow the pipeline to show better things at a glance. I have no idea how to do such "tee" bits in GitHub Actions (though I haven't looked in a while, the artifacts usage seem…convoluted compared to GitLab's "here's a list of globs"). For that matter, "join"s would be nice too (e.g., to collect the 20 or so wheels built across various jobs into one `twine` upload).