Re: [PATCH] automation: avoid duplicated builds of staging branch

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Jul 21, 2023 at 04:42:11PM -0700, Stefano Stabellini wrote:
> On Mon, 17 Jul 2023, Marek Marczykowski-Górecki wrote:
> > On Mon, Jul 17, 2023 at 02:14:14PM +0100, Andrew Cooper wrote:
> > > On 17/07/2023 2:09 pm, Marek Marczykowski-Górecki wrote:
> > > > "staging" branch is mirrored (automatically or manually) to several
> > > > repositories. Avoid building it several times to not waste runner
> > > > resources.
> 
> Hi Marek,
> 
> Let me try to understand the use-case a bit better. You would like the
> following "staging" branch to run a full pipeline:
> https://gitlab.com/xen-project/xen
> 
> But if someone under xen-project/people is mirroring
> https://gitlab.com/xen-project/xen, this patch is attempting to skip the
> additional pipeline. For instance, if I am mirroring staging in my
> personal repo:
> 
> https://gitlab.com/xen-project/people/sstabellini/xen
> 
> We are skipping the additional pipeline there.

Yes.

> Is that correct? If so, it would be easier to ask everyone to make sure
> they have "Trigger pipelines for mirror updates" unselected:
> 
> https://docs.gitlab.com/ee/user/project/repository/mirror/pull.html#trigger-pipelines-for-mirror-updates

If that's set in gitlab as pull mirror (instead of push from somewhere
else), then that indeed may be enough. But is it really in all those
cases?

> > > > Signed-off-by: Marek Marczykowski-Górecki 
> > > > <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> > > > ---
> > > >  .gitlab-ci.yml | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > index c8bd7519d5fb..c3b05e32636b 100644
> > > > --- a/.gitlab-ci.yml
> > > > +++ b/.gitlab-ci.yml
> > > > @@ -2,6 +2,12 @@ stages:
> > > >    - build
> > > >    - test
> > > >  
> > > > +workflow:
> > > > +  rules:
> > > > +    - if: '$CI_COMMIT_REF_NAME == "staging" && $CI_PROJECT_NAMESPACE 
> > > > != "xen-project"'
> > > > +      when: never
> > > > +    - when: always
> > > 
> > > If we're doing this for staging, we should include staging-* and
> > > stable-*.  They're all the same from this point of view.
> > > 
> > > However, this does need double checking with the committers who use
> > > gitlab regularly (CC'd).  This doesn't happen to interfere with my
> > > commit workflow (I use a separate branch called for-staging), but I
> > > can't talk for others.
> > 
> > I'd like to avoid broad patterns like staging-* or stable-* here, I'm
> > pretty sure people do use branches like staging-X.Y-something. While it
> > would be possible to exclude them by listing exact names, I'm not sure
> > if it's worth it, given the push frequency to them (few times a month)
> > and those being mirrored to less repositories (only FuSa fork?).


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature