From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Beraldo Leal" <bleal@redhat.com>
Subject: Re: [PATCH 3/5] gitlab: stable staging branches publish containers in a separate tag
Date: Wed, 17 May 2023 16:37:53 +0100 [thread overview]
Message-ID: <ZGT00cm2rocMyv3E@redhat.com> (raw)
In-Reply-To: <8e6c152f-4349-f63e-9976-0f9cd412f8df@tls.msk.ru>
On Wed, May 17, 2023 at 06:26:56PM +0300, Michael Tokarev wrote:
> 17.05.2023 16:54, Daniel P. Berrangé wrote:
> > If the stable staging branches publish containers under the 'latest' tag
> > they will clash with containers published on the primary staging branch,
> > as well as with each other. This introduces logic that overrides the
> > container tag when jobs run against the stable staging branches.
> >
> > The CI_COMMIT_REF_SLUG variable we use expands to the git branch name,
> > but with most special characters removed, such that it is valid as a
> > docker tag name. eg 'staging-8.0' will get a slug of 'staging-8-0'
> >
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > .gitlab-ci.d/base.yml | 24 ++++++++++++++++++++++--
> > 1 file changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/.gitlab-ci.d/base.yml b/.gitlab-ci.d/base.yml
> > index a1d734267a..f379c182a7 100644
> > --- a/.gitlab-ci.d/base.yml
> > +++ b/.gitlab-ci.d/base.yml
> > @@ -1,7 +1,7 @@
> > variables:
> > - # On stable branches this needs changing. Should also be
> > - # overridden per pipeline if running pipelines concurrently
> > + # On stable branches this is changed by later rules. Should also
> > + # be overridden per pipeline if running pipelines concurrently
> > # for different branches in contributor forks.
> > QEMU_CI_CONTAINER_TAG: latest
> > @@ -16,6 +16,9 @@ variables:
> > # Thus we group them into a number of stages, ordered from
> > # most restrictive to least restrictive
> > #
> > +# For pipelines running for stable "staging-X.Y" branches
> > +# we must override QEMU_CI_CONTAINER_TAG
> > +#
> > .base_job_template:
> > variables:
> > # Each script line from will be in a collapsible section in the job output
> > @@ -61,11 +64,23 @@ variables:
> > #############################################################
> > # Optional jobs should not be run unless manually triggered
> > + - if: '$QEMU_JOB_OPTIONAL && $CI_PROJECT_NAMESPACE == $QEMU_CI_UPSTREAM && $CI_COMMIT_BRANCH =~ /staging-[[:digit:]]+\.[[:digit:]]/'
> > + when: manual
> > + allow_failure: true
> > + variables:
> > + QEMU_CI_CONTAINER_TAG: $CI_COMMIT_REF_SLUG
>
> Here, it somehow feels better to use $CI_COMMIT_BRANCH instead of $CI_COMMIT_REF_SLUG.
> I know little about gitlab CI. It is REF_SLUG like a hashed value of COMMIT_BRANCH?
The git branch / tag name can contain characters that are not permitted
for docker tag names. The CI_COMMIT_REF_SLUG is CI_COMMIT_BRANCH but with
everything except 0-9 and a-z replaced with -, making it safe for use as
a docker tag [1].
With regards,
Daniel
[1] https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
--
|: 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 :|
next prev parent reply other threads:[~2023-05-17 15:38 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é
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é [this message]
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=ZGT00cm2rocMyv3E@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=bleal@redhat.com \
--cc=mjt@tls.msk.ru \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).