Circleci, Travis, and gitlab all allow you to ssh into the box you are trying your scripts on and fix it there. Much easier and takes a lot less time. Github actions have an unofficial way of doing it and is…not the best. Actions is actually one of the worst CIs I’m my experience.
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).
Circleci, Travis, and gitlab all allow you to ssh into the box you are trying your scripts on and fix it there. Much easier and takes a lot less time. Github actions have an unofficial way of doing it and is…not the best. Actions is actually one of the worst CIs I’m my experience.
Their move to attempt to monetize our on-prem runners might be the kick needed to move to Gitlab 🤞
Gl!
That’s so silly.
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).