News for hackers. Stuff that matters.

A comment on The End of CI. Parent comment

Re:The End of CI by viraptor on Sunday July 03, 2022 @07:33AM (#31966908)
You can go a step further. Instead of merging anything, you can tell the ci to merge it. Then ci can make a "merge-test" branch, run all the tests on it, and if they pass, then ff-merge it to master for real. No need for "good chance" or rebasing just to keep up with master.

It does take some extra work though, because GH and others don't really support this out of the box.

[ Parent | on HN ]
Re:The End of CI by marcusarmstrong on Sunday July 03, 2022 @08:59AM (#31967371)
Gitlab does support this with “Merged Result pipelines”[0]. We use them extensively alongside their merge train functionality to sequential is everything and it’s fantastic.

[0]: https://docs.gitlab.com/ee/ci/pipelines/merged_results_pipel...

[ Parent | on HN ]
Re:The End of CI by zelos on Sunday July 03, 2022 @10:19AM (#31967864)
Isn’t this the way everyone works? Write code, run some tests/linting locally, then create a PR to master and the CI server runs all the tests and reports pass/fail. Changes without a pass can’t be merged to master.
[ Parent | on HN ]
Re:The End of CI by charcircuit on Sunday July 03, 2022 @03:01PM (#31970080)
The extra step is that once the change is accepted the process of rebasing it or merging it into master is done by a bot that checks if it would break master before preceding to do it.

My issue with this approach is that it becomes tricky to scale since you can only have one job running at a time. Allowing master to potentially break scales better because you can run a job for each commit on master which hasn't been evaluated. Technically you could make that approach work by instead of rebasing onto master rebasing onto the last commit that is being tested, but this adds extra complexity which I don't think standard tooling can easily handle.

[ Parent | on HN ]
Re:The End of CI by viraptor on Sunday July 03, 2022 @05:05PM (#31971029)
> you can only have one job running at a time

https://zuul-ci.org/ and some other systems solve it by optimistic merges. If there's already a merge job running, the next one assumes that will succeed. And tests on merged master + first change + itself. If anything breaks, the optimistic merges are dropped from the queue and everything starts from the second chance only. Openstack uses it and it works pretty well if the merges typically don't fail.

[ Parent | on HN ]
Re:The End of CI by throwaway858 on Sunday July 03, 2022 @03:04PM (#31970108)
This can result in a broken master if there were new commits added to master since the pull request was submitted (but before it is merged).

The solution is to require that all PR must be rebased/synced to master before they can be merged. GitHub has an option for enforcing this. The downside is that this often results in lots of re-running of tests.

[ Parent | on HN ]