fyi.

this patch should remove the jenkins jobs https://gerrit.ovirt.org/#/c/77342/1
Once its merged you can delete the automation dir on the project itself.

ah, ok, thanks for clarification.

to answer - well, the project decided to go through a more simple way than what's currently implemented for most other ovirt projects, being quite different in technology and scope. It works well and I do not see a need for more complex verification any time soon.(It doesn't mean it cannot be consumed by OST like anything else, I just currently do not see any way how would it be useful)
The automation dir is getting in a way just in the sense of the broken jobs. So..it saves some common oVirt infrastructure resources.

If you just remove 'automation', you'll just get broken jobs. You need to remove the jobs themselves by removing the project YAML from the 'jenkins' repo.

, I wonder what is being requested from infra? Why you can't simply remove the automation/ directory in the project when it's not needed? Does it break anything?

The infra team doesn't monitor projects builds/jobs, it's up to the maintainer responsibility to monitor it and make sure it is working, and if there is an infra issue to report to infra.
Have you reported the failure to infra?

If you remove 'build-artifacts' it means you will never be able to include the project in the oVirt system tests verification flow and other than minimal testing in Travis only for the project itself, you won't have any system level testing done before a release or delivery to QE.

I don't follow how automation dir is getting in your development or testing and what do you consider minimizing it, can you elaborate?

cc fyi.

The build-artifacts had to be failing for a couple of last weeks, no complain received.

Did you try to ask the CI team for help?

The project is built externally (copr) and rpms are pulled semi-automatically (project releng-tools, Sandro).

releng-tools just pulls into official repos, and hopefully we'll retire that way of doing things soon. Among other things it means the package does not make in into the nightly releases.

Is CI really involved? If so, what is the minimum of automation/ to remain?

Not sure I get the 1st part of the question.

At bare minimum to get stuff into the 'experimental' flow that runs OST and delivers to 'tested' and the nightly snapshot, you need a build_artifacts job. It doesn't really has to do the building, but it needs to leave RPMs in 'exported-artifacts' when it is done.

The build-artifacts had to be failing for a couple of last weeks, no complain received.
The project is built externally (copr) and rpms are pulled semi-automatically (project releng-tools, Sandro).

Is CI really involved? If so, what is the minimum of automation/ to remain?

You mean remove 'check-patch' ?
We can't remove build-artifacts because it is needed for oVirt testing and
composes.

On Thu, May 25, 2017 at 1:53 PM, Marek Libra (oVirt JIRA) <

–

Eyal edri

ASSOCIATE MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D

Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)