Hacker News Reader

Comment by sossunday | Hacker News Reader

> git push origin

> Push my code to the remote; likely spinning up lots of machines in CI to check my work.

That's a good callout; something that I have noticed I frequently miss when iterating on my code is the cost of the CI/CD systems already set up. It's something to consider especially when iterating using a system like Sapling for Stacked PRs; each individual PR push may update a chain which causes a lot of wasted CI/CD time.

View on HN

I feel that a lot of my colleagues use "git push" as a backup mechanism, but GitLab actually supports that workflow via `git push -o ci.skip` to distinguish between "yes, just back up my commits" versus "ok, I'm really ready to test them". I'm aware of the commit-message hack used by other CI systems, but I much prefer that out-of-band mechanic

They have a ton of other handy toys, even if the syntax is ... Very Git :-( https://docs.gitlab.com/ee/user/project/push_options.html#pu... I suggested a feature-request to add `git push -o gitlab.help`: https://gitlab.com/gitlab-org/gitlab/-/issues/359267 as well as showing the CLI equivalent for the web workflow:

CI variables: https://gitlab.com/gitlab-org/gitlab/-/issues/359268

MR: https://gitlab.com/gitlab-org/gitlab/-/issues/359269

Especially if you're using a finite pool of CI runners. Lots of companies do run their own CI runners either for added security, or to get persistent CI machines with a hot local cache so builds/tests are much faster. Then everyone's PRs are blocked waiting for CI machines just because of people's weird push workflows or micro stacked PRs

Reply on news.ycombinator.com