GitLab local checks

[full lodge]

Love this idea! Is there a GitLab API for updating a check on the project/repo? if so, should be easy to do 🙂

[slow lark]

Looks a lot like DHH's hot takes 🙂 https://x.com/dhh/status/1896932150055997517?t=j4ZASdSnyhF0Jp_rVZJfLA&s=19

DHH (@dhh) on X

Our new GitHub extension for local CI sign-offs make it easy to prevent PRs from being merged until tests, linters, and security checks have all been run on the developer machine. Enjoy! https://t.co/yfhCqlkr1n

X · Mar 4, 2025, 2:34 PM

[steel sun]

Thanks for your reply! I'm not sure if I'm following, do you mean the gitlabci triggers a workflow on my own machine? Or what would the flow look like 🧐

[steel sun]

The tweet doesn't seem to load, but I can imagine him saying something like that yeah haha

[slow lark]

it's coming from this article: https://world.hey.com/dhh/we-re-moving-continuous-integration-back-to-developer-machines-3ac6c611

[steel sun]

Yeah great take imo!

I've not yet found a great solution for this, will checkout how DHH did it for github

[slow lark]

@steel sun you might also like @rugged steppe's kubecon presentation which also revolves around to this topic: https://www.youtube.com/watch?v=tsH3eTo2GLI

[steel sun]

Pretty cool. Seems like good ideas

[steel sun]

So right now I'm thinking of the following challenges:

Environment variables used by the steps

• I could probably set something up with 1password so that all environment variables are shared
• There would probably need to be some kind of sha hash for guarantees

How does the Gitlab CI runner know which steps to do and which steps to skip

• The dagger local steps could be triggered by a precommit hook, that adds a certain

How can the Gitlab CI runner know with absolute certainty that the local CI has ran with the exact same configuration as it would have run in the runner

• Hashes?
• Maybe just share the cache somehow, so it runs but all computation can be skipped?

Disclaimer, I've not yet daggerized anything. So some of there challenges might already been solved by dagger. I'm gonna play with dagger now, I'm hyped for this

[deft storm]

hi Tony here, i too am a devops engineer and have similar goals as Pieter. i am just getting started and the main challenge on my mind is Peiter’s second bullet, although i am thinking of the problem a little differently. i am thinking of running dagger in Gitlab runner in addition to on dev workstation, the idea being the developer can develop with quick CI cycles, but still need to open MR to run the “official” pipeline, the difference being the developer does not push and pray they push with confidence and less often. i also would like the Gitlab CI pipeline to be very simple, just one dagger job, so my question is how to map the current Gitlab rules into the logic in my dagger code, which is what i take Pieter’s second bullet to mean… am i unrealistic to think i can move all logic, including rules (ie what runs when) into dagger, or are most people still maintaining multiple Gitlab jobs that call specific dagger functions?