There is gitlab-runner exec command which takes a ci yaml file and executes it, but it sux (A LOT), so they deprecated it.
This is not the same as taking a bash/powershell script and running it locally on runners host because gitlab inject into shell some stuff like secrets, env vars, artifacts, caches etc.
Some errors are VERY hard to reproduce when not on local executing environment.
I agree! I think that we have lots of improvements to make here. One feature that is underutilized (more on that in a second) that tries to answer this is our [1] interactive web terminal that lets you connect directly to the container or runner that is running a job. Would love feedback on how that could maybe help here.
Now, having said that there are two issues still open that are top of mind for making this minimal viable change much more usable. One is making the Web Terminal work in our shared runner pool on GitLab.com [2]. This is obviously required for users of .com who don't want to bring their own runner and something we're working closely with our Production and Security teams on making a reality.
In addition, there is a command today of `gitlab-runner exec` that allows you (in theory) to install the GitLab runner locally and execute it on your development machine. However, we technically depreciated that and have plans to re-implement it in a more useful way. [3]
This is not the same as taking a bash/powershell script and running it locally on runners host because gitlab inject into shell some stuff like secrets, env vars, artifacts, caches etc.
Some errors are VERY hard to reproduce when not on local executing environment.