[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/5] gitlab: centralize the container tag name
|
From: |
Daniel P . Berrangé |
|
Subject: |
Re: [PATCH 1/5] gitlab: centralize the container tag name |
|
Date: |
Fri, 26 May 2023 11:33:33 +0100 |
|
User-agent: |
Mutt/2.2.9 (2022-11-12) |
On Fri, May 26, 2023 at 12:31:21PM +0200, Thomas Huth wrote:
> On 26/05/2023 12.20, Daniel P. Berrangé wrote:
> > On Fri, May 26, 2023 at 09:25:39AM +0200, Thomas Huth wrote:
> > > On 17/05/2023 15.54, Daniel P. Berrangé wrote:
> > > > We use a fixed container tag of 'latest' so that contributors' forks
> > > > don't end up with an ever growing number of containers as they work
> > > > on throwaway feature branches.
> > > >
> > > > This fixed tag causes problems running CI upstream in stable staging
> > > > branches, however, because the stable staging branch will publish old
> > > > container content that clashes with that needed by primary staging
> > > > branch. This makes it impossible to reliably run CI pipelines in
> > > > parallel in upstream for different staging branches.
> > > >
> > > > This introduces $QEMU_CI_CONTAINER_TAG global variable as a way to
> > > > change which tag container publishing uses. Initially it can be set
> > > > by contributors as a git push option if they want to override the
> > > > default use of 'latest' eg
> > > >
> > > > git push gitlab <branch> -o ci.variable=QEMU_CONTAINER_TAG=fish
> > > >
> > > > this is useful if contributors need to run pipelines for different
> > > > branches concurrently in their forks.
> >
> > >
> > > This patch no longer applies ... could you please rebase and resend a v2?
> > > Thanks!
> >
> > I've rebased and sent a v2, but I didn't get any conflits when
> > rebasing, so v1 should have applied OK.
>
> git-am is sometimes more picky than git-rebase ... I think there were some
> contextual conflicts with the patches from Camilla (commit 5f63a67adb5847
> and b105ce60ca8bdee3) ... I should have maybe tried with "--3way" first
> before complaining, sorry.
No worries, it is annoying that git am doesn't default to enabling -3,
as that's basically always what you want :-(
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- Re: [PATCH 5/5] gitlab: support disabling job auto-run in upstream, (continued)