CI require a 'lgtm' or 'ok-to-test' labels to run

[ant31]

• Implement script changes to require a 'lgtm' or 'ok-to-test' label for running CI
• Update the 'moderator' stage rules to not run the job by default unless specific conditions are met

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
To stop running 'expensive' CI on all PR without a maintainer review.

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ant31

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ant31]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[VannTen]

Is that going to work for the following :

• new PR -> initial needs-ok-to-test
• some time passes
• org member adds the label (via comment and the prow automation) ok-to-test or lgtm -> will the PR trigger at that point ?

[ant31]

org member adds the label (via comment and the prow automation) ok-to-test or lgtm -> will the PR trigger at that point

yes
I was thinking of having a /retest too to 're-trigger' i.
Labels events are received too and could be use also to trigger it automatically.

Created this PR first to check if the labels are published and can be used for rules.

[ant31]

/hold

[ant31]

/ok-to-test

[ant31]

/assign @VannTen

The pipeline is retried automatically when the labels "lgtm" or "ok-to-test" are applied
otherwise it will be blocked at the moderator stage.

[ant31]

/unhold

[VannTen]

The pipeline is retried automatically when the labels "lgtm" or "ok-to-test" are applied otherwise it will be blocked at the moderator stage.

Maybe it should be `has: lgtm or not(has:needs-ok-to-test)` otherwise it would block CI for org members right ?

[VannTen]

Also, should we skip CI for `do-not-merge/work-in-progress` ? That's what prow does but we don't necessarily need to do the same.

[ant31]

Maybe it should be has: lgtm or not(has:needs-ok-to-test) otherwise it would block CI for org members right ?

Org member can apply themselve ok-to-test, why would it block CI ?

do-not-merge/work-in-progress

I think it's fine, the ok-to-test is explicit, you either have it applied or not.
I don't want to have to complicate rules

[ant31]

I suggest we give it a try and chant it quickly if something is not working or annoying.

[VannTen]

Fine by me, that was mainly for consistency with the rest of kubernetes-sigs where the ok-to-test is implicit for org-members.
One last question:
What happens if a PR modify the .gitlab-ci.yml ? Does that allow to bypass the check ?

[ant31]

What happens if a PR modify the .gitlab-ci.yml

@VannTen, yes, it has always been the case.

To fix that, failfast-ci would have to 'fail' the sync before and not trigger the pipeline at all, which is doable.
Ideally that would happen only if any of the ci files is modified.

[VannTen]

> What happens if a PR modify the .gitlab-ci.yml @VannTen, yes, it has always been the case. To fix that, failfast-ci would have to 'fail' the sync before and not trigger the pipeline at all, which is doable. Ideally that would happen only if any of the ci files is modified.

Ok, let's go with this and keep that for later, 👍 /lgtm

[ant31]

your /lgtm has triggered the pipeline -_- .

I'll try to fix that in a follow-up to not run twice( one for ok-to-test, one for lgtm)