Re: new procedure with GitLab CI

[Jonas Hahnfeld]

Am Freitag, den 29.05.2020, 22:47 +0200 schrieb David Kastrup:
> So I lean towards the following process modeled upon our old one:
> 
> No push to master except by automation.  Staging is unprotected and gets
> scheduled runners.  People ultimately rebase and push there once they
> get Patch-push status.  Default branch can be master as long as we make
> sure that one cannot push there: that way you never rebase on ephemeral
> commits.
> 
> When James gives Patch-push status (which he hopefully does supported by
> a script), at the same time any merge request pointed at master gets
> changed to point at staging.  So if you are "Patch-push", the "Push"
> button starts working.
> 
> That means as long as staging isn't stuck (and we should make sure that
> the scheduled pipelines do not pick up the same commit more than once to
> avoid wasting our minutes), you can rebase on master when you want (or
> not).  One initial pipeline run should be require to get into "Review"
> state.  Rebasing puts you back to "Patch-new" (which for trivial stuff
> you may choose to hand-replace with "Patch-review" at the danger of
> later getting staging borked).
> 
> It would be nice that if staging has tested as being borked, we could
> temporarily disable pushes to staging: that will keep the patches and
> merge requests requiring redoing limited.  We got out along without that
> previously but if the automation is good for that, that would be great.
> 
> At any rate, this scheme naively does not seem to require stuff
> impossible to do with Gitlab, at least for the basic parts of operation.
> And it would mean that you can usually rebase and forget without waiting
> for pipeline completions.  And you get the liberty of bypassing most CI
> and rebases if you don't want to.
> 
> I may be wrong about the possibility to do this with a reasonable amount
> of effort: I don't want to get hopes up unnecessarily.

I thought about this since you proposed it last weekend. I think the
following could be possible without too much work:
If somebody wants to merge multiple MRs at once, we create a temporary
staging branch. Now merge all MRs into that one and open a new MR to
merge the staging branch into master. This will run all pipelines as
usual and can be "merged if pipelines succeed".

If that's still not enough to avoid contention, I encourage you to try
implementing alternatives in a private repository. By now, I'm fed up
enough that I don't want to spend more time for this topic.

Jonas

signature.asc
Description: This is a digitally signed message part