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.
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.
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).
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 -fgoes pretty dang fast and 60 % of the time third time’s the charm.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.
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).