All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Beraldo Leal" <bleal@redhat.com>
Subject: Re: [PATCH 1/5] gitlab: centralize the container tag name
Date: Fri, 26 May 2023 11:33:33 +0100	[thread overview]
Message-ID: <ZHCK/VVMnPPxKHSZ@redhat.com> (raw)
In-Reply-To: <6a3e792e-757e-61f5-ca2d-c1933c0cf0ee@redhat.com>

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 :|



  reply	other threads:[~2023-05-26 10:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-17 13:54 [PATCH 0/5] gitlab: improvements to handling of stable staging branches Daniel P. Berrangé
2023-05-17 13:54 ` [PATCH 1/5] gitlab: centralize the container tag name Daniel P. Berrangé
2023-05-17 15:17   ` Michael Tokarev
2023-05-17 20:01   ` Richard Henderson
2023-05-26  7:25   ` Thomas Huth
2023-05-26 10:20     ` Daniel P. Berrangé
2023-05-26 10:31       ` Thomas Huth
2023-05-26 10:33         ` Daniel P. Berrangé [this message]
2023-05-17 13:54 ` [PATCH 2/5] gitlab: allow overriding name of the upstream repository Daniel P. Berrangé
2023-05-17 15:18   ` Michael Tokarev
2023-05-17 13:54 ` [PATCH 3/5] gitlab: stable staging branches publish containers in a separate tag Daniel P. Berrangé
2023-05-17 15:26   ` Michael Tokarev
2023-05-17 15:37     ` Daniel P. Berrangé
2023-05-17 13:54 ` [PATCH 4/5] gitlab: avoid extra pipelines for tags and stable branches Daniel P. Berrangé
2023-05-17 15:27   ` Michael Tokarev
2023-05-17 13:54 ` [PATCH 5/5] gitlab: support disabling job auto-run in upstream Daniel P. Berrangé
2023-05-17 15:13   ` Michael Tokarev
2023-05-17 15:38     ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZHCK/VVMnPPxKHSZ@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=bleal@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.