Georges Racinet (c0f9c7e6) at 26 Mar 09:40
convert-merge-rails: always convert even if merge process stalled
... and 5 more commits
Georges Racinet (a10f367c) at 20 Mar 13:42
convert-merge-rails: precision about NMC count in issues
... and 3 more commits
Georges Racinet (50e3e0e4) at 20 Mar 13:42
upstream-merge-stats: ability to compare to upstream head
Georges Racinet (3e034b26) at 12 Mar 09:48
convert-merge-rails: precision about NMC count in issues
... and 4 more commits
Georges Racinet (6607d2f6) at 12 Mar 09:48
upstream-merge-stats: ability to compare to upstream head
... and 1 more commit
Georges Racinet (fe7c4e18) at 12 Mar 09:48
Issue for release branch start when reaching upstream branching point
Georges Racinet (ea0a01bd) at 11 Mar 10:19
convert-merge-rails: precision about NMC count in issues
Georges Racinet (cfa632d6) at 10 Mar 19:46
convert-merge-rails: precision about NMC count in issues
... and 4 more commits
Georges Racinet (44b875e9) at 10 Mar 19:45
upstream-merge-stats: ability to compare to upstream head
... and 1 more commit
Georges Racinet (5b4056e0) at 10 Mar 19:45
Issue for release branch start when reaching upstream branching point
Georges Racinet (0455e204) at 06 Mar 10:40
convert-merge-rails: precision about NMC count in issues
Georges Racinet (78d9d1d6) at 06 Mar 10:28
convert-merge-rails: display count of non-merge changesets in issues
... and 3 more commits
Georges Racinet (3f0c18dc) at 28 Feb 14:59
Issue for release branch start when reaching upstream branching point
When the upstream merge process reaches an upstream minor version branching point, we have work to do: typically starting a Heptapod release branch.
Even in the current catch-up phase during which not all upstream minor versions give rise to a Heptapod release, we still have to bump Omnibus and create a tag in order to be able to come back to it and release a posteriori if needed for data migrations.
In all cases, it is better to stop the upstream merge process, and filing an issue with the "Upstream merge" label does exactly that. Since we have a template for the release branch creation, it would spare us a manual action to use it right away.
We are still merging all Omnibus changes for a minor version at once, and sometimes have build failures that would not happen if there was less lag.
We should genericise convert_merge_rails
so that it can handle other components. GitLab Shell could also be a candidate, but it is usually less time consuming to do manually.
This is also a prerequisite for heptapod#1367
Currently, if a topic brings in less changesets than --min-mr-weight
, the MR is not created.
This is fine, but in the case when the process stopped on a version branching point, the MR must be created nevertheless.
This is especially true because simply resuming will happily proceed to add more changesets that we do not want yet, since we are now past the branching point. This would not be a total disaster (if the branching point is published early, we can always tag it after the fact), but the new changesets can induce CI problems that make them harder to validate without changing things in the support infrastructure that we don't want to change until after the branching point.
It's been working a couple of times now.
Georges Racinet (5af8e61e) at 05 Jan 12:44
convert-merge-rails: improve Gitaly changes issue template
Georges Racinet (422c33fb) at 21 Dec 18:13
convert-merge-rails: auto-resolution in Issue and MR Templates
... and 1 more commit
Georges Racinet (6ec921f4) at 21 Dec 18:13