Re: xen | Failed pipeline for staging | b819bd65

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.04.2024 11:58, Andrew Cooper wrote:
> On 30/04/2024 10:00 am, Jan Beulich wrote:
>> On 30.04.2024 10:03, GitLab wrote:
>>>
>>> Pipeline #1272869158 has failed!
>>>
>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>> Branch: staging ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>>
>>> Commit: b819bd65 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/commit/b819bd65f4fb25be582f66ba2e4134f61d86f459
>>>  )
>>> Commit Message: revert "x86/mm: re-implement get_page_light() u...
>>> Commit Author: Jan Beulich ( https://gitlab.com/jbeulich )
>>>
>>>
>>> Pipeline #1272869158 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/pipelines/1272869158 ) 
>>> triggered by Jan Beulich ( https://gitlab.com/jbeulich )
>>> had 3 failed jobs.
>>>
>>> Job #6745823842 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/jobs/6745823842/raw )
>>>
>>> Stage: test
>>> Name: adl-pci-hvm-x86-64-gcc-debug
>>> Job #6745823720 ( 
>>> https://gitlab.com/xen-project/hardware/xen/-/jobs/6745823720/raw )
>>>
>>> Stage: analyze
>>> Name: eclair-x86_64
>> This flags start_nested_{svm,vmx}() as regressions, when the regression was
>> previously spotted already. Is that intended?
> 
> Yes.
> 
>>  I.e. shouldn't the comparison
>> be to the previous pipeline run, such that issues are pointed out only for
>> what is actually being added anew with the patch / batch under test?
> 
> Why should it be?

I understand what you say below, but to answer this question: It results in
wasted time looking at failures. I don't think it would be a good takeaway
of mine if, from now on, I simply ignored such failures. Thus I'd like it to
be the case that known failures can be easily told from new ones.

Jan

>  That's unlike every other CI we use, even OSSTest.
> 
> Gitlab, like many others, is stateless between runs.
> 
> These violations are ones where we had got down to 0 in Xen, and Xen was
> marked as "clean" for these rules.  Any nonzero count (in the subset of
> things we think we've fixed fully) is a failure.
> 
> This is no different to e.g. a panic on boot.  OSSTest will keep on
> complaining of a regression until it gets fixed.
> 
> ~Andrew