[Engine-devel] Proposal for new commit msg design for engine commits

[Giuseppe Vallarelli]

Hi Eyal, I really appreciate your concern and desire to streamline our
CI infrastructure, but I'm afraid there might be some issues worth of
discussing.

If I've understood correctly a developer should add some kind of tags
to idenfity the impact of the patch and so the subsets of tests (impact areas)
that are going to be executed. I think it might be hard in some cases to
properly identify the correct 'areas' and even error prone. I think that
it really depends on how much engine software components are independent
from each other and developer's codebase knowledge. I think it might be useful
to have a dependency graph of components let's say at package level to define
which tests should be executed, perhaps this is something that can be automate.
We might discover that for transitivity a component depends on the whole
engine.

My 2 Czech Crowns

Cheers, Giuseppe




----- Original Message -----
| From: "Eyal Edri" <eedri at redhat.com>
| To: "engine-devel" <engine-devel at ovirt.org>
| Cc: "infra" <infra at ovirt.org>
| Sent: Tuesday, July 9, 2013 11:38:51 AM
| Subject: [Engine-devel] Proposal for new commit msg design for engine commits
| 
| Hi,
| 
| You all probably know and familiar with 'ovirt-engine' git hook for commit
| msg template [1].
| this helps understand the general area of the patch in the project but it
| lacks additional info that might
| be valuable for scaling automatic tests in Jenkins CI.
| 
| Let me explain:
| 
| Infra team is working hard on expanding oVirt CI infrastructure and adding
| more tests in jenkins (per commit/patch).
| Adding important meta-data per patch can significatly improve the ability to
| run specific tests for each patch/commit,
| and not waste valuable resources on Jenkins jobs that are not relevant to the
| code in the patch.
| 
| So the idea is to add/expand current metadata per patch, in the form of:
| (either)
|  1. expanding current header template to include more data like 'network' ,
|  'setup', 'tools', 'virt'
|  2. adding a new label with relevant tags for the patch, called e.g
|  'METADATA: network, rest, virt'
| 
| Jenkins jobs will then be able to parse that data and trigger only relevant
| jobs for it.
| this can also allow us to add more jobs per patch, an option that is very
| problematic today considering the amount of
| patches coming in to engine.
| 
| Once agreed on a format, we'll be able to add a git hook to verify the
| validity of the commit msg. (similar to bug-url).
| 
| if we're not 100% sure that the tags will cover all corner cases and we feel
| like we need to run the code on all jobs,
| we can a nightly job to run all the remaining jobs (but at least it won't run
| on every patch/commit).
| 
| [1] <core | restapi | tools | history | engine | userportal | webadmin>:
| 
| 
| thoughts?
| 
| Eyal Edri.
| _______________________________________________
| Engine-devel mailing list
| Engine-devel at ovirt.org
| http://lists.ovirt.org/mailman/listinfo/engine-devel
|