Actually there is a ticket [1] to remove all dao tests jobs and move them to STD CI, But as Barak said the jobs can't run without a DB and postgres installed, so support should be added to the STD ci code (probably copying it and adjust from the current jobs?) Example of existing dao tests job: http://jenkins.ovirt.org/job/ovirt-engine_master_dao-unit-tests_created/1495... [1] https://ovirt-jira.atlassian.net/browse/OVIRT-450 On Mon, Mar 28, 2016 at 6:52 AM, Barak Korren <bkorren@redhat.com> wrote:
On 27 March 2016 at 20:57, Yevgeny Zaspitsky <yzaspits@redhat.com> wrote:
Hi All,
I renamed NetworkAttachmentDaoTest.java to NetworkAttachmentDaoImplTest.java (note the added "Impl") and Jenkins now includes the test in the regular unit-tests run rather than running that as a dao-unit-tests job. That causes test to fail as it cannot connect ot the tests DB.
Where the logic of choosing the right configuration sits? Shouldn't any dal change trigger the dao tests rather than the regular ones?
I'm not sure which project are you referring to, but if you are talking about a project which uses Standard CI, then all the logic resides either in the scripts in the automation directory or in the tools they invoke. The only logic which does not sit there (for now) is which of the 3 Std-CI stages to run for which OS.
What this means WRT the above is that the logic to set up the test DB needs to be embedded in the automation script (probably check_patch.sh) as well as the logic to decide which patch to run.
-- Barak Korren bkorren@redhat.com RHEV-CI Team _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)