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/14952/consoleFull


[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)