mbox series

[XEN,0/3] automation/eclair: do not allow failure for triggered analyses

Message ID cover.1714401209.git.federico.serafini@bugseng.com (mailing list archive)
Headers show
Series automation/eclair: do not allow failure for triggered analyses | expand

Message

Federico Serafini April 29, 2024, 3:21 p.m. UTC
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(-)

Comments

Andrew Cooper May 3, 2024, 7:14 p.m. UTC | #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
Federico Serafini May 3, 2024, 7:44 p.m. UTC | #2
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.
Andrew Cooper May 3, 2024, 7:46 p.m. UTC | #3
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
Federico Serafini May 3, 2024, 8:01 p.m. UTC | #4
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?
Andrew Cooper May 3, 2024, 8:06 p.m. UTC | #5
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
Nicola Vetrini May 6, 2024, 6:45 a.m. UTC | #6
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