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

[Vaclav Petras]

On Tue, 20 Feb 2024 at 06:45, Nicklas Larsson via grass-dev <
grass-dev at lists.osgeo.org> wrote:

>
> On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev <
> 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.
>

The backports and releases are done using direct commits and pushes. That's
how the rules are set, no bypass or exception is necessary for that.

I guess the issue is not that we can't bypass the check but that we want
the checks to pass because we don't want to base the release on a commit
with failing CI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20240220/04cb8382/attachment.htm>