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]
CodeShip is also a SaaS and is, "Forever free: You can use up to 100 builds per month for free, with unlimited projects and unlimited team members."
We are also working at CloudBees to have CodeShip support the emerging Jenkins X Pipeline syntax (YAML that mirrors the functionality of the Jenkins Pipeline). This syntax was based on the Tekton project, driven by the Continuous Delivery Foundation and significantly influenced by Jenkins developers like Andrew Bayer and Devin Nusbaum and by their PM, Nofar Bluestein.
100 builds per month ? I have more then that in a day for medium size projects!
No, nothing in the cloud, no system you don't fully control is an option in my IT business. Forever. The only thing I tolerate is something totally irrelevant most of the time, (like statuspage maybe), easily replaceable and package repositories (but only because you can install local proxy so once pulled is on premise FOREVER).
You haave to install the runner on the target, then you can use exec, plus a switch to allow it to run as root. The key is it has to be configured on the target device _first_.
Then you have a root shell on your target device (I leave the "should" as an exercise for the user )
But, It won't work using the free shared gitlab runners.
The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.