On Mon, Feb 26, 2018 at 1:06 PM, Edward Haas <ehaas@redhat.com> wrote:

On Mon, Feb 26, 2018 at 12:16 PM, Dan Kenigsberg <danken@redhat.com> wrote:

...

On Sat, Feb 24, 2018 at 4:36 PM, oVirt Jenkins <jenkins@ovirt.org> wrote:

...

Change 83979,8 (vdsm) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed.

This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed.

For further details about the change see: https://gerrit.ovirt.org/#/c/83979/8

For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5850/

...

I see that one of the network functional tests is failing build-artifacts and the release of this build.

Edy, could you see why?

http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x8 6_64/3226/artifact/exported-artifacts/mock_logs/mocker-epel- 7-x86_64.el7.check-merged.sh/check-merged.sh.log

The functional tests are running on a Lago VM, which crashed (the timeout kicked in). But I do not see the relevance between the artifact build and the check-merge, the later is not a gateway to any automation step I know of at the moment (for good and for worse, mainly worse).

The build fails due to vdsm_master_build-artifacts-fc27-s390x <http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc27-s390x/> , which is failing for some time now. Who can look into that? The lago VM crash is a secondary less urgent issues, although it will be nice if it can be investigated as well. Last time, it failed on a specific slave frequently (a non Centos one). Thanks, Edy.

did you re-trigger the job? there are actually two failed aftifacts for that change. The point is that if you fail even one of the build-artifacts jobs that CQ will not even start to run on your change since we expect the build-artifacts you selected for your project to pass. I think that what Eyal meant on the check-patch job is that if you want to integrate a new distro you should probably stabilize it first and a good way of doing it is not to add it to your build-artifacts job bit treat it as an independent job that would be run on check-patch. that way, you can find the failures on check-patch, and if you cannot fix them you can still decide to merge the patch and it would not to run CQ on your patch since the build-artifacts is not in your required artifacts list. On Mon, Feb 26, 2018 at 11:06 AM, Edward Haas <ehaas@redhat.com> wrote:

On Mon, Feb 26, 2018 at 12:16 PM, Dan Kenigsberg <danken@redhat.com> wrote:

...

On Sat, Feb 24, 2018 at 4:36 PM, oVirt Jenkins <jenkins@ovirt.org> wrote:

...

Change 83979,8 (vdsm) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed.

This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed.

For further details about the change see: https://gerrit.ovirt.org/#/c/83979/8

For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5850/

I see that one of the network functional tests is failing build-artifacts and the release of this build.

Edy, could you see why?

http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x8 6_64/3226/artifact/exported-artifacts/mock_logs/mocker-epel- 7-x86_64.el7.check-merged.sh/check-merged.sh.log

The functional tests are running on a Lago VM, which crashed (the timeout kicked in). But I do not see the relevance between the artifact build and the check-merge, the later is not a gateway to any automation step I know of at the moment (for good and for worse, mainly worse).

_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra