Jonas Hahnfeld <[email protected]> writes: > Am Donnerstag, den 21.05.2020, 14:29 +0200 schrieb David Kastrup: >> Jonas Hahnfeld <[email protected]> writes: >> > Am Dienstag, den 19.05.2020, 08:08 -0400 schrieb Dan Eble: >> > > On May 17, 2020, at 15:27, Jonas Hahnfeld <[email protected]> wrote: >> > > > before merging. As we only allow fast-forward merges, this means each >> > > > MR has received testing in the form it hits master. This would >> > > > effectively replace the current setup of pushing to staging. >> > > >> > > I'm for this. >> > >> > Thanks. What do others (David, Han-Wen, Valentin) think about this? >> > There's certainly room for improvement, but with an initial setup I can >> > start writing documentation. >> >> The "traffic jam" problem could be avoided by retaining the option of >> pushing to staging. That would occur without CI, but one could >> occasionally trigger the merge with CI on staging to have everything in >> it migrate to master. Since staging would be used by the more >> experienced people desiring to bunch their work before testing, the >> triggering could also happen manually by whoever thinks he has pushed >> enough stuff to staging to give it a whirl. > > That's not really how CI works. With our policy of FF merges, what > happens if some MR get merged directly to master and some sit in > staging? You'd probably rebase staging which triggers another CI > pipeline and doesn't buy you much.
It buys you that several commits are bunched in staging and are treated in bulk. At least I think it does. > I don't mind deciding that we don't want to enable CI right now. The > purpose of bringing this up now is that I didn't want to spend time > documenting something that's going to change the next day. In my > opinion, having CI and merging to master feels more "natural" than the > staging setup. And finally if contention proves to be a problem, we > can still revert to the old setup. I was more going for the mixed bag right now :) -- David Kastrup
