automation/eclair_analysis/ECLAIR/analysis.ecl | 4 ++++ automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +- automation/gitlab-ci/analyze.yaml | 1 - 3 files changed, 5 insertions(+), 2 deletions(-)
Patch 1/3 does some preparation work.
Patch 2/3, as the title says, removes allow_failure = true for triggered
analyses.
Patch 3/3 makes explicit that initally no files are tagged as adopted, this
is needed by the scheduled analysis.
Federico Serafini (3):
automation/eclair: tag Rule 7.2 as clean and temporarily remove Rules
1.1 and 8.2
automation: do not allow failure for triggered analyses
automation/eclair: make explicit there are no adopted files by default
automation/eclair_analysis/ECLAIR/analysis.ecl | 4 ++++
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
automation/gitlab-ci/analyze.yaml | 1 -
3 files changed, 5 insertions(+), 2 deletions(-)
--
2.34.1
On 29/04/2024 4:21 pm, Federico Serafini wrote: > Patch 1/3 does some preparation work. > > Patch 2/3, as the title says, removes allow_failure = true for triggered > analyses. > > Patch 3/3 makes explicit that initally no files are tagged as adopted, this > is needed by the scheduled analysis. I'm afraid that something in this series is broken. Since these patches went in, all pipelines are now getting a status of blocked rather than passed. If I manually start the Eclair jobs, then eventually the pipeline gets to Passed. ~Andrew
On 03/05/24 21:14, Andrew Cooper wrote: > On 29/04/2024 4:21 pm, Federico Serafini wrote: >> Patch 1/3 does some preparation work. >> >> Patch 2/3, as the title says, removes allow_failure = true for triggered >> analyses. >> >> Patch 3/3 makes explicit that initally no files are tagged as adopted, this >> is needed by the scheduled analysis. > > I'm afraid that something in this series is broken. > > Since these patches went in, all pipelines are now getting a status of > blocked rather than passed. > > If I manually start the Eclair jobs, then eventually the pipeline gets > to Passed. Can you provide us a link to those failures? I am looking at gitlab xen-project/xen and xen-project/patchew and everything seems ok. -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com)
On 03/05/2024 8:44 pm, Federico Serafini wrote: > On 03/05/24 21:14, Andrew Cooper wrote: >> On 29/04/2024 4:21 pm, Federico Serafini wrote: >>> Patch 1/3 does some preparation work. >>> >>> Patch 2/3, as the title says, removes allow_failure = true for >>> triggered >>> analyses. >>> >>> Patch 3/3 makes explicit that initally no files are tagged as >>> adopted, this >>> is needed by the scheduled analysis. >> >> I'm afraid that something in this series is broken. >> >> Since these patches went in, all pipelines are now getting a status of >> blocked rather than passed. >> >> If I manually start the Eclair jobs, then eventually the pipeline gets >> to Passed. > > Can you provide us a link to those failures? > I am looking at gitlab xen-project/xen and xen-project/patchew > and everything seems ok. > https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1276081658 is the first one I noticed as blocked, and I manually ran. That ended up working. https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1277724847 is still in the blocked state. The build-each-commit failure is unrelated. ~Andrew
On 03/05/24 21:46, Andrew Cooper wrote: > On 03/05/2024 8:44 pm, Federico Serafini wrote: >> On 03/05/24 21:14, Andrew Cooper wrote: >>> On 29/04/2024 4:21 pm, Federico Serafini wrote: >>>> Patch 1/3 does some preparation work. >>>> >>>> Patch 2/3, as the title says, removes allow_failure = true for >>>> triggered >>>> analyses. >>>> >>>> Patch 3/3 makes explicit that initally no files are tagged as >>>> adopted, this >>>> is needed by the scheduled analysis. >>> >>> I'm afraid that something in this series is broken. >>> >>> Since these patches went in, all pipelines are now getting a status of >>> blocked rather than passed. >>> >>> If I manually start the Eclair jobs, then eventually the pipeline gets >>> to Passed. >> >> Can you provide us a link to those failures? >> I am looking at gitlab xen-project/xen and xen-project/patchew >> and everything seems ok. >> > > https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1276081658 > is the first one I noticed as blocked, and I manually ran. That ended > up working. > > https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1277724847 > is still in the blocked state. The build-each-commit failure is unrelated. This is intentional and was introduced by commit 7c1bf8661db5c00bd8c9a25015fe8678b2ff9ac6 The ECLAIR analysis under people/* need to be activated manually. Is this causing some problems to the CI? -- Federico Serafini, M.Sc. Software Engineer, BUGSENG (http://bugseng.com)
On 03/05/2024 9:01 pm, Federico Serafini wrote: > On 03/05/24 21:46, Andrew Cooper wrote: >> On 03/05/2024 8:44 pm, Federico Serafini wrote: >>> On 03/05/24 21:14, Andrew Cooper wrote: >>>> On 29/04/2024 4:21 pm, Federico Serafini wrote: >>>>> Patch 1/3 does some preparation work. >>>>> >>>>> Patch 2/3, as the title says, removes allow_failure = true for >>>>> triggered >>>>> analyses. >>>>> >>>>> Patch 3/3 makes explicit that initally no files are tagged as >>>>> adopted, this >>>>> is needed by the scheduled analysis. >>>> >>>> I'm afraid that something in this series is broken. >>>> >>>> Since these patches went in, all pipelines are now getting a status of >>>> blocked rather than passed. >>>> >>>> If I manually start the Eclair jobs, then eventually the pipeline gets >>>> to Passed. >>> >>> Can you provide us a link to those failures? >>> I am looking at gitlab xen-project/xen and xen-project/patchew >>> and everything seems ok. >>> >> >> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1276081658 >> is the first one I noticed as blocked, and I manually ran. That ended >> up working. >> >> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1277724847 >> is still in the blocked state. The build-each-commit failure is >> unrelated. > > This is intentional and was introduced by > commit 7c1bf8661db5c00bd8c9a25015fe8678b2ff9ac6 > > The ECLAIR analysis under people/* need to be activated > manually. Yes. I know, and that matches the behaviour I saw. > > Is this causing some problems to the CI? > Yes. See https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines Prior to this series, the manual actions were not used but the pipeline was overall in the Passed state. Specifically, they ended up being skipped. After this series, the manual actions are now blocking the pipeline, not letting it complete, and not marking it as passed. ~Andrew
On 2024-05-03 22:06, Andrew Cooper wrote: > On 03/05/2024 9:01 pm, Federico Serafini wrote: >> On 03/05/24 21:46, Andrew Cooper wrote: >>> On 03/05/2024 8:44 pm, Federico Serafini wrote: >>>> On 03/05/24 21:14, Andrew Cooper wrote: >>>>> On 29/04/2024 4:21 pm, Federico Serafini wrote: >>>>>> Patch 1/3 does some preparation work. >>>>>> Hi, >>>>>> Patch 2/3, as the title says, removes allow_failure = true for >>>>>> triggered >>>>>> analyses. >>>>>> >>>>>> Patch 3/3 makes explicit that initally no files are tagged as >>>>>> adopted, this >>>>>> is needed by the scheduled analysis. >>>>> >>>>> I'm afraid that something in this series is broken. >>>>> >>>>> Since these patches went in, all pipelines are now getting a status >>>>> of >>>>> blocked rather than passed. >>>>> >>>>> If I manually start the Eclair jobs, then eventually the pipeline >>>>> gets >>>>> to Passed. >>>> >>>> Can you provide us a link to those failures? >>>> I am looking at gitlab xen-project/xen and xen-project/patchew >>>> and everything seems ok. >>>> >>> >>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1276081658 >>> is the first one I noticed as blocked, and I manually ran. That >>> ended >>> up working. >>> >>> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1277724847 >>> is still in the blocked state. The build-each-commit failure is >>> unrelated. >> >> This is intentional and was introduced by >> commit 7c1bf8661db5c00bd8c9a25015fe8678b2ff9ac6 >> >> The ECLAIR analysis under people/* need to be activated >> manually. > > Yes. I know, and that matches the behaviour I saw. > >> >> Is this causing some problems to the CI? >> > > Yes. > > See https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines > > Prior to this series, the manual actions were not used but the pipeline > was overall in the Passed state. Specifically, they ended up being > skipped. > > After this series, the manual actions are now blocking the pipeline, > not > letting it complete, and not marking it as passed. one way to fix this can be to set allow_failure when in the people/* branches, which will cause the stage to be skipped and thus mark the pipeline as Passed when all other steps have completed. See https://gitlab.com/xen-project/people/bugseng/xen/-/pipelines/1278550868 -- Nicola Vetrini, BSc Software Engineer, BUGSENG srl (https://bugseng.com)
© 2016 - 2024 Red Hat, Inc.