3 ms·

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 c

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).

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).