Re: [XEN PATCH v2] automation/eclair: add new analysis jobs with differing configurations

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 29 Oct 2025, Nicola Vetrini wrote:
> On 2025-10-29 01:22, Stefano Stabellini wrote:
> > On Tue, 28 Oct 2025, Nicola Vetrini wrote:
> > > On 2025-10-28 00:58, Stefano Stabellini wrote:
> > > > On Fri, 24 Oct 2025, Nicola Vetrini wrote:
> > > > > The following analysis jobs are performed:
> > > > > - eclair-{x86_64,ARM64}: analyze Xen using the default configuration
> > > for
> > > > >   that architecture; runs on runners tagged `eclair-analysis'.
> > > > >
> > > > > - eclair-{x86-64,ARM64}-safety: analyze Xen using the configuration
> > > for
> > > > >   safety, which is more restricted; runs on runners tagged
> > > > >   `eclair-analysis-safety`.
> > > > >
> > > > > - eclair-{x86_64,ARM64}-testing: analyze Xen using the default
> > > > >   configuration for the purposes of testing new runner updates; runs
> > > on
> > > > >   runners tagged `eclair-analysis-testing`.
> > > > >
> > > > > Signed-off-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
> > > >
> > > > Do you have a link to a successful pipeline?
> > > >
> > > > Just making sure we are not breaking things.
> > > >
> > > 
> > > No; not yet, at least [1]. Without the right tags the safety runner can't
> > > pick
> > > up jobs.
> > > 
> > > [1]
> > > https://gitlab.com/xen-project/people/bugseng/xen/-/pipelines/2117835680
> > > 
> > > >
> > > > > ---
> > > > > Changes in v2:
> > > > > - rebased to current staging;
> > > > > - fixed regex path issue.
> > > > > ---
> > > > >  automation/gitlab-ci/analyze.yaml | 38
> > > +++++++++++++++++++++++++++++++
> > > > >  1 file changed, 38 insertions(+)
> > > > >
> > > > > diff --git a/automation/gitlab-ci/analyze.yaml
> > > > > b/automation/gitlab-ci/analyze.yaml
> > > > > index d50721006740..7bd644d75074 100644
> > > > > --- a/automation/gitlab-ci/analyze.yaml
> > > > > +++ b/automation/gitlab-ci/analyze.yaml
> > > > > @@ -45,6 +45,21 @@ eclair-x86_64:
> > > > >      LOGFILE: "eclair-x86_64.log"
> > > > >      VARIANT: "X86_64"
> > > > >      RULESET: "monitored"
> > > > > +
> > > > > +eclair-x86_64-testing:
> > > > > +  extends: eclair-x86_64
> > > > > +  tags:
> > > > > +    - eclair-analysis-testing
> > > > > +  rules:
> > > > > +    - if: $CI_PROJECT_PATH =~ /^xen-project\/people\/bugseng.*$/
> > > > > +      when: always
> > > > > +    - !reference [.eclair-analysis:triggered, rules]
> > > >
> > > > given that everyone can change this yaml file when pushing to their own
> > > > branch, I think we should remove this, or (probably better) use a
> > > > separate env variable to set the default
> > > >
> > > > it is better not to use the path, I think
> > > >
> > > 
> > > That is a fair concern. One option would be to just use a project runner
> > > assigned to the people/bugseng/xen subproject, but that might be a bit
> > > inconvenient if we want to swap runners around.
> > 
> > I think it is OK to register a project runner to people/bugseng/xen. I
> > am happy with this solution as well.
> > 
> > 
> > > Another option, as you said,
> > > is keeping the regex in a variable, but this wont't prevent rogue
> > > modifications of the YAML.
> > 
> > I was thinking more of a simpler boolean variable like:
> > 
> > rules:
> >   - if: $ECLAIR_TESTING
> > 
> > Yes, it wouldn't prevent modifications of the YAML, but it is probably
> > not an issue? Also, it is not less secure than the path, because the
> > YAML can be changed by anyone. At least the variable is more flexible
> > and feels more natural.
> > 
> 
> Ok, let's use the variable and then change if we see any problems. I'll send a
> v3. If you could add the tags to the runners in the meantime, I can validate
> the changes with a proper CI run.

I added the tag eclair-analysis-testing to the runner