For gitlab this is only correct with a shell executor which is to be avoided in the general case in favor of a docker or k8s executor for isolation&repeatability.

Those you can actually run locally with gitlab-runner, but then you won't have all your gitlab instance's CI variables so it's a PITA if you need a CI token which you probably do if you actually make decent use of gitlab's features.

In most cases I just end up committing my changes to avoid the headache. :!git commit --amend --no-edit && git push -f goes pretty dang fast and 60 % of the time third time's the charm.

[–] mesamunefire@piefed.social 2 points 6 days ago* (last edited 6 days ago) (1 children)

Why avoid the shell executor on docker? I did 4years of gitlab back a bit ago. It was super simple. But I haven't kept up since work maintains actions and Travis. And there's a way nowadays to inject the env or pull from a secret server-ish.

All ci is basically the same. Or at least for a while.

[–] azertyfun@sh.itjust.works 1 points 6 days ago (1 children)

Ideally you'd use the docker executor with a dind service instead of docker commands in the shell. You'll have better isolation (e.g. no conflicts from open port forwards) and better forward-compatibility (the pipeline won't break every time a major upgrade is applied to the runner because the docker - especially compose - CLI is unstable).

[–] mesamunefire@piefed.social 1 points 5 days ago

I can see the dependencies mucking everything up.