But is it a _complicated_ YAML file?

You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript CI script. It's pretty widely known that you should keep as much stuff out of the YAML as possible, so you can run CI locally.

That was definitely the most bullshit criticism in the article. Clearly not even something they actually care about because they settled on Drone CI which is configured in exactly the same way.

> You don't have to make Gitlab/GitHub YAML files complicated if you don't want to. The "script" section can be just a call to a normal shell/Python/Typescript CI script.

It took me an embarrassingly long time to learn that you don't need to use their little action plugins for everything.

Once I figured that out, and figured out how to run CI in a container specified by the repo, I was actually quite happy to transition my CI away from Jenkins (which was always pretty rough, but I knew I could keep the builds running locally that way).

I guess the real proof will be if I'm able to ever leave GitHub, but I feel pretty good about the amount of lock-in vs the benefits of the service.

> to run CI in a container specified by the repo

Would you happen to have an example YAML at hand?

Here's one:

https://github.com/ahepp/resume/blob/d7778b1339271cbd7812634...

It uses GitHub's devcontainer plugin. There's a devcontainer config at .devcontainer/devcontainer.json, which says to use the image specified by .ci/Dockerfile.

So when I'm developing on any Linux system, I can run

    $ docker build .ci/Dockerfile -t my-container
    $ docker run --rm -it -v $(pwd):/project -w /project my-container

And have a shell with my LaTeX environment all ready to go.

I can also create a GitHub codespace from the devcontainer config. I'm excited to explore more of the possibilities with devcontainers. I've included Dockerfiles with all my projects for quite a while now, it's cool to have some kind of standard written down that tooling can be written for.

I think the GitHub YAML a slight improvement over the old Jenkins configs it replaced:

https://github.com/ahepp/resume/commit/a144ee06b868ae867b287...

For one, there's no out-of-band Jenkins UI I need to configure the pipeline in. The syntax is probably a slight improvement over Jenkins. I'm also happy to use opaque plugins for certain things, like uploading to S3.

Thank you for sharing! This shows nicely how you can keep the GitHub YAML at minimum by referring to an action (in this case devcontainers/ci) which configures itself based on the content of the repo.

They never start that way, do they?

On other CI systems it is also a good idea to only use the YAML file to call a bash/python/deno/... script which does the actual work.

Might as well be just a text file with a command to run.

You still need some high level structure to define jobs running on different platforms and their dependencies, so that jobs can run in parallel. Doesn't need to be written in YAML of course, or even declarative style.

it's also not "just cloning Git repos and running commands"