[GRASS-dev] GRASS GIS: backport of CI speed updates to G83?

[Edouard Choinière]

Releasebranches don’t require workflows to pass now so he cannot use auto-merge.

But once tests of the OSGeo4W are started, since they don’t fail the CI, you could just not wait, it won’t change anything.

Edouard Choinière

Le 20 févr. 2024 à 06:45, Nicklas Larsson <n_larsson at yahoo.com> a écrit :


On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev <grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>> wrote:


In fact the slowest CI run determines how much time I have to wait
with each release step (i.e., editing VERSION file, wait 1:30hs, do
some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION
file, wait 1:30hs ... which is a pain).


I agree this is a case where we have limited ourself too much, with all those
required 1.5 hrs tests, approval, etc. (not even [skip ci] would work) . What you
would need is a (ideally) direct commit access or at least  “Rebase and merge”
option to merge (thus enable a number of commits to be merged at one time,
as opposed to "Squash and merge”).

We must find a solution to improve this situation for preparing releases, I
wouldn’t mind temporary lifting necessary constraints.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20240220/2736db8f/attachment-0001.htm>