[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH 2/2] automation/eclair: avoid unintentional ECLAIR analysis
On 14/08/2023 23:52, Stefano Stabellini wrote:
On Mon, 14 Aug 2023, Stefano Stabellini wrote:
On Sat, 12 Aug 2023, Simone Ballarin wrote:
> On 12/08/2023 00:04, Stefano Stabellini wrote:
> > On Fri, 11 Aug 2023, Simone Ballarin wrote:
> > > With this patch, ECLAIR jobs will need to be manually
> > > started for "people/.*" pipelines.
> > >
> > > This avoids occupying the runner on analyzes that might
> > > not be used by developers.
> > >
> > > If developers want to analyze their own repositories
> > > they need to launch them from GitLab.
> > >
> > > Signed-off-by: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
> > > ---
> > > automation/gitlab-ci/analyze.yaml | 14 ++++++++++----
> > > automation/gitlab-ci/build.yaml | 6 ------
> > > automation/gitlab-ci/test.yaml | 5 -----
> > > 3 files changed, 10 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/automation/gitlab-ci/analyze.yaml
> > > b/automation/gitlab-ci/analyze.yaml
> > > index 4aa4abe2ee..f04ff99093 100644
> > > --- a/automation/gitlab-ci/analyze.yaml
> > > +++ b/automation/gitlab-ci/analyze.yaml
> > > @@ -20,21 +20,27 @@
> > > codequality: gl-code-quality-report.json
> > > needs: []
> > >
> > > -eclair-x86_64:
> > > +.eclair-analysis:triggered:
> > > extends: .eclair-analysis
> > > + allow_failure: true
> > > + rules:
> > > + - if: $CI_PROJECT_PATH =~ /^xen-project\/people\/.*$/
> > > + when: manual
> > > + - when: always
> > > +
> > > +eclair-x86_64:
> > > + extends: .eclair-analysis:triggered
> > > variables:
> > > LOGFILE: "eclair-x86_64.log"
> > > VARIANT: "X86_64"
> > > RULESET: "Set1"
> > > - allow_failure: true
> > >
> > > eclair-ARM64:
> > > - extends: .eclair-analysis
> > > + extends: .eclair-analysis:triggered
> > > variables:
> > > LOGFILE: "eclair-ARM64.log"
> > > VARIANT: "ARM64"
> > > RULESET: "Set1"
> > > - allow_failure: true
> > >
> > > .eclair-analysis:on-schedule:
> > > extends: .eclair-analysis
> >
> > Everything so far looks great and I am ready to Ack.
> >
> >
> > > diff --git a/automation/gitlab-ci/build.yaml
> > > b/automation/gitlab-ci/build.yaml
> > > index 173613567c..e4b601943c 100644
> > > --- a/automation/gitlab-ci/build.yaml
> > > +++ b/automation/gitlab-ci/build.yaml
> > > @@ -12,11 +12,6 @@
> > > - '*/*.log'
> > > when: always
> > > needs: []
> > > - except:
> > > - - master
> > > - - smoke
> > > - - /^coverity-tested\/.*/
> > > - - /^stable-.*/
> > >
> > > .gcc-tmpl:
> > > variables: &gcc
> > > @@ -269,7 +264,6 @@
> > > .test-jobs-artifact-common:
> > > stage: build
> > > needs: []
> > > - except: !reference [.test-jobs-common, except]
> > >
> > > # Arm test artifacts
> > >
> > > diff --git a/automation/gitlab-ci/test.yaml
> > > b/automation/gitlab-ci/test.yaml
> > > index 8ccce1fe26..11cb97ea4b 100644
> > > --- a/automation/gitlab-ci/test.yaml
> > > +++ b/automation/gitlab-ci/test.yaml
> > > @@ -1,11 +1,6 @@
> > > .test-jobs-common:
> > > stage: test
> > > image: registry.gitlab.com/xen-project/xen/${CONTAINER}
> > > - except:
> > > - - master
> > > - - smoke
> > > - - /^coverity-tested\/.*/
> > > - - /^stable-.*/
> > >
> > > .arm64-test-needs: &arm64-test-needs
> > > - alpine-3.18-arm64-rootfs-export
> >
> > These changes instead belongs to the first patch, right?
>
> Yes, sorry. Moreover, it is the answer to your question on
> the other patch.
No problem. Please re-send. One more comment. In the first patch we
have:
+workflow:
+ rules:
+ - if: $CI_COMMIT_BRANCH =~
/^(master|smoke|^coverity-tested\/.*|stable-.*)$/
+ when: never
+ - when: always
I think it is an excellent idea to skip "master" as well as the
others,
but maybe we could make them "manual" instead of "never" just in case
someone wants to see the results on master. It might happen on special
occasions.
"when:manual" cannot be used at workflow-level, but only at job-level.
I've made a couple of experiments and I found several problems in doing
that
related to the clauses "allow_failure" and "needs".
One more thing: today the Eclair jobs always start even if WTOKEN is
not
defined (hence the jobs cannot actually succeed). Would it make sense
to
also add a check on the existence of WTOKEN? If WTOKEN exists, start
the
Eclair jobs, otherwise do not ?
No problem.
--
Simone Ballarin, M.Sc.
Field Application Engineer, BUGSENG (https://bugseng.com)
|
