Re: [PATCH 2/2] gitlab: don't run CI jobs by default on push to user forks

[Thomas Huth]

(meta note: patch does not apply anymore and needs to be refreshed)

On 12/08/2021 20.04, Daniel P. Berrangé wrote:
[...]
> diff --git a/.gitlab-ci.d/rules.yml b/.gitlab-ci.d/rules.yml
> new file mode 100644
> index 0000000000..3399722ca9
> --- /dev/null
> +++ b/.gitlab-ci.d/rules.yml
> @@ -0,0 +1,116 @@
> +
> +# This defines rules used to control individual job execution
> +# See docs/devel/ci-jobs.rst for an explanation of the various
> +# variables and branch naming conventions applied here.
> +#
> +.job_rules:
> +  rules:
> +    # ======================================================================
> +    # Rules that apply regardless of whether the primary qemu repo or a fork
> +    # ======================================================================
> +
> +    # Skip any cirrus job if either repo or api token are missing
> +    # as we won't be able to talk to cirrus
> +    - if: '$CIRRUS_VM_INSTANCE_TYPE && ($CIRRUS_GITHUB_REPO == null || 
> $CIRRUS_API_TOKEN == null)'
> +      when: never
> +
> +    # Any jobs marked as manual, never get automatically run in any scenario
> +    # and don't contribute to pipeline status
> +    - if: '$QEMU_JOB_MANUAL'
> +      when: manual
> +      allow_failure: true
> +
> +    # For the main repo, tags represent official releases.
> +    # The branch associated with the release will have passed
> +    # a CI pipeline already
> +    #
> +    # For user forks, tags are tyically added by tools like

s/tyically/typically/

> +    # git-publish at the same time as pushing the branch prior
> +    # to sending out for review
> +    #
> +    # In neither case do we wish to run CI pipelines for tags
> +    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_TAG'
> +      when: never

Not sure whether I like this rule ... First, tags are very seldom compared 
to normal pushes to branches, so this should not affect us that much. 
Second, I think it might be good for "documentation" purposes to be able to 
say that the CI ran properly for a certain tag. Ok, you could still look it 
up in the push to a branch that might have happened before, but that's 
cumbersome. Just my 0.02 €.

> +
> +    # ====================================
> +    # Rules for running jobs in user forks
> +    # ====================================
> +
> +    # Part 1: gating jobs
> +    # -------------------
> +
> +    # If on a branch with name prefix 'ci-acceptance-', then run
> +    # everything, just as a gating job on 'staging' branch would
> +    - if: '$CI_COMMIT_BRANCH =~ /^ci-gating-/'
> +      when: on_success
> +
> +    # If user set QEMU_CI_GATING=1, then run everything just as
> +    # a gating job on 'staging' branch would
> +    - if: '$QEMU_CI_GATING'
> +      when: on_success
> +
> +    # Otherwise never run jobs marked as gating, but allow manual trigger
> +    # without affecting pipeline status
> +    - if: '$QEMU_JOB_GATING'
> +      when: manual
> +      allow_failure: true

IMHO if it's "gating", then we should not use "allow_failure: true", no 
matter whether the job is manual or not. Otherwise this is very confusing.

I guess the problem is rather whether the "acceptance" tests should be 
called "gating" or not. Currently they are in a rather gray area in the 
gitlab-CI...

> +
> +    # =============================================
> +    # Part 2: opt-in for all CI, except gating jobs
> +    # =============================================
> +
> +    # If pushing to a branch with name prefix 'ci-all', then run all jobs
> +    - if: '$CI_COMMIT_BRANCH =~ /^ci-all/'
> +      when: on_success
> +
> +    # If user QEMU_CI_ALL=1, then run all jobs
> +    - if: '$QEMU_CI_ALL'
> +      when: on_success

Uh, so "all" is not running all jobs? ... that's confusing, too. Could you 
come up with some better naming? QEMU_CI_CORE maybe?

[...]
> +Set variable manually when pushing to git
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   Variables can be set manually when pushing a branch or tag, using
> -git-push command line arguments.
> +git-push command line arguments. This is useful for fine tuning the
> +jobs on an adhoc basis.

s/adhoc/ad hoc/ (I think)

 Thomas