qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Thomas Huth" <thuth@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Willian Rampazzo" <willianr@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: [PATCH 0/2] gitlab: limit jobs executed in most pipelines by default
Date: Mon, 19 Jul 2021 13:12:13 +0100	[thread overview]
Message-ID: <20210719121215.2356409-1-berrange@redhat.com> (raw)

The QEMU pipeline has as many as 120+ jobs, almost all of which are
always run. This is wasteful in many ways. When merging to the main
repo, Peter runs CI on 'staging' branch, which then gets immediately
re-run on the 'master' branch.  The first patch in this series
culls that redundancy by always skipping CI on pushes to 'master'.

I suggest we setup a nightly scheduled job that runs on current
contents of 'master' once a day, as a way to catch bitrot from OS
distro's changing under us.

I think we want the first patch as a high priority, since I think
the duplicated jobs on master are really impacting our integration
with Cirrus CI, delaying jobs since Cirrus has very strictly
applied concurrency limits.



The second patch is more speculative, and illustrates how to we
can reduce the number of CI jobs run for *all* contributors,
when they push to gitlab. There is a key decision to make here
between:

 a. run no jobs at all by default on push
 b. run a few jobs by default on push to catch 90% of problems
 c. run all jobs on by default on push

Currently we're doing (c), and patch 2 implements (b), with an
easy opt-in to trigger (c).

There is a credible variant of patch 2 though, which could easily
implement (a) with an opt-in to run (b), and a further opt-in to
run (c).

Or we can get more advanced and add ability for individual
contributors to decide between (a) and (b) for default behaviour,
based on a variable configured globally in their gitlab fork.

There is an illustration of results of (b) here:

   https://gitlab.com/berrange/qemu/-/pipelines/339281325

Note that for all the non-defualt jobs, I've left them as
manually triggerable. This makes a the pipeline UI a bit
cluttered by default but lets you trigger jobs from the
web UI individually. An alternative would be to never
create the non-defualt jobs at all. They would have to be
requested explicitly at time of push in some way.

Daniel P. Berrangé (2):
  gitlab: prevent CI jobs running pushes to default branch or tags
  gitlab: cut down on jobs run by default in user forks

 .gitlab-ci.d/buildtest-template.yml  |  17 +---
 .gitlab-ci.d/buildtest.yml           |  14 +++
 .gitlab-ci.d/cirrus.yml              |   5 +-
 .gitlab-ci.d/container-core.yml      |   3 +
 .gitlab-ci.d/container-cross.yml     |   9 +-
 .gitlab-ci.d/container-template.yml  |   1 +
 .gitlab-ci.d/containers.yml          |   2 +
 .gitlab-ci.d/crossbuild-template.yml |   3 +
 .gitlab-ci.d/crossbuilds.yml         |   3 +
 .gitlab-ci.d/qemu-project.yml        |   1 +
 .gitlab-ci.d/workflow.yml            | 146 +++++++++++++++++++++++++++
 .gitlab-ci.yml                       |  21 +---
 12 files changed, 188 insertions(+), 37 deletions(-)
 create mode 100644 .gitlab-ci.d/workflow.yml

-- 
2.31.1




             reply	other threads:[~2021-07-19 12:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19 12:12 Daniel P. Berrangé [this message]
2021-07-19 12:12 ` [PATCH 1/2] gitlab: prevent CI jobs running pushes to default branch or tags Daniel P. Berrangé
2021-07-19 12:12 ` [PATCH 2/2] gitlab: cut down on jobs run by default in user forks 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=20210719121215.2356409-1-berrange@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    --cc=willianr@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).