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? 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
