Re:Minimum Viable Git for Trunk-Based Development
by dapirian on Wednesday November 30, 2022 @11:31AM
(#33803168)
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
Re:Minimum Viable Git for Trunk-Based Development
by mdaniel on Wednesday November 30, 2022 @12:32PM
(#33804212)
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
> 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.