Having to push a commit to test the Github equivalent (Actions) was a huge pain. I think I ended up with 80+ commits.
I wish the existing solutions on the Github side worked.
Mildly ironic that you're hosting this on Github.
Show HN: Test your Gitlab CI Pipelines changes locally using Docker
31–40 of 41 posts
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#32Earlier quoted context omitted.
Yeah I thought about that, but gitlab-runner doesn't allow to "share" cache or artifacts between jobs so it's not a good fit to test multiple-jobs workflows.
Sure it does. Jobs have a shared cache (although this can be slow) and artifacts are shared to downstream jobs. Maybe this is a tiered feature? https://docs.gitlab.com/ee/ci/caching/
When using the "exec" command it doesn't do that. It just executes one job, not the whole pipeline.
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#33IMO you can do this without needing extra tooling if you keep your CI scripts as shell scripts and your application is running in Docker. If you keep your CI scripts as shell scripts and put them into a runnable file included in your project you can run your CI scripts locally so you can test the work flow on your machine. It's also handy in case CI is down you can still test and deploy your code. Lastly it lets you…
Same, my CI has looked like this for years now: ./script/prepare-env ./script/test ./script/build ./script/deploy It's worked in virtually every CI system, and locally. Bonus point, it really points out the amount of ceremony some CI platforms require to map simple commands into their pipelines. Looking at you, CircleCI.
I found an approach like this was especially nice on teamcity in conjunction with its template feature.
Individual apps were still able to have whatever specific thing they needed, but you could globally add a step, eg a security scanning tool or slack notification by modifying the template only rather than 100s of build configuration files as the GitHub / circleci approach seems to encourage.
Adding a new pipeline basically just meant naming it and selecting the VCS URL
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#34Having to push a commit to test the Github equivalent (Actions) was a huge pain. I think I ended up with 80+ commits. I wish the existing solutions on the Github side worked. Mildly ironic that you're hosting this on Github.
> I wish the existing solutions on the Github side worked.
I did experience a bad outcome using act[0] for a super weird matrix-y workflow, but I'd say for the most part it behaved sanely; did you report your complaints to their issue tracker?
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#35This looks great! I hate it when I have to commit and push a new change for a simple bug. That being said, how does this differ from something like act [1] (besides the fact this is for Gitlab)? [1] https://github.com/nektos/act
> (besides the fact this is for Gitlab)?
Heh, yeah, besides being a different programming language, how is node different from Java? :-D
I, too, would value "the one CI yaml to rule them all" but given how much faster GitLab is moving than GitHub, there's almost no prayer of them trying to have some kind of common behavior.
I actually had the best experience using circleci's local runner (back when we were using it for CI) as far as "run binary, perform build" goes. I have yet to see gitlab-runner successfully execute a local build :-(
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#36Having to push a commit to test the Github equivalent (Actions) was a huge pain. I think I ended up with 80+ commits. I wish the existing solutions on the Github side worked. Mildly ironic that you're hosting this on Github.
> I wish the existing solutions on the Github side worked. I did experience a bad outcome using act[0] for a super weird matrix-y workflow, but I'd say for the most part it behaved sanely; did you report your complaints to their issue tracker? 0 = https://github.com/nektos/act
I briefly tried it. It couldn’t even parse the yaml.
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#37This looks interesting. Will test it out. Hope it works with includes.
Yeah it does work with includes. One of the pain point right now is that it does not work with cache:untracked or artifacts:untracked, but I'm trying to figure it out :)
Haha, I have nothing that relies on that, so should be fine for me.
I guess you do something like secretly make separate artifact folders per job and keep copying (or just linking) stuff around?
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#38How does this differ from Earthly? https://github.com/earthly/earthly
Earthly lets you abstract anything you do inside a container into an Earthfile, that runs locally on a dev's machine, but also in any CI, making CI scripts more portable. However, testing other CI-specific things before committing, such as GitLab rules dictating when jobs actually run, remain unsolved. But they also remain unsolved with this glci solution, right?
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#39Great idea. One question - what pain point is this solving? As a GitLab, GitLab Pipeline and Docker user I don't find running pipelines that slow to run or initiate
From what I understand, you use it as a test for your pipeline scripts. With code we run unittest locally to make sure our commits are okay. When develop ci scripts, many times you only find out things don't work until you push the ci scripts to GitLab, it leaves you with many try and fix commits in history.
Re: Show HN: Test your Gitlab CI Pipelines changes locally using Docker
#40Having to push a commit to test the Github equivalent (Actions) was a huge pain. I think I ended up with 80+ commits. I wish the existing solutions on the Github side worked. Mildly ironic that you're hosting this on Github.
> I think I ended up with 80+ commits.
Happens all the time to me. (although I have not used Actions) . Especially when I also had to set up a cross compiler on the CI. And each change needs 15 minutes to run the VM again
CI is an enormous productivity killer