----- Original Message ----- > From: "Alon Bar-Lev" <[email protected]> > To: "Eyal Edri" <[email protected]> > Cc: "engine-devel" <[email protected]>, "infra" <[email protected]> > Sent: Tuesday, July 9, 2013 3:33:57 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > commits > > > > ----- Original Message ----- > > From: "Eyal Edri" <[email protected]> > > To: "engine-devel" <[email protected]> > > Cc: "infra" <[email protected]> > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > Subject: 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' > > Please do not expand header, it is too short anyway. > > > 2. adding a new label with relevant tags for the patch, called e.g > > 'METADATA: network, rest, virt' > > Having: > > CI-Tests: xxx > CI-Tests: yyy > CI-Tests: zzz > > Is much better.
I'm not sure we should have CI-Test - as we might use this for something else besides CI. Region_of_Interest as Dan suggests sounds better IMHO. > > However, I don't think that it is the responsibility of the committer. > > I suggested some time ago to have metadata information within each source. > > Each source should have metadata of: > > 1. Maintainer group. Not sure if this is always relevant, what if i'm fixing some unit test that got broken? it's enough to know I'm a maintainer, no? > 2. Subsystem. > 3. Any other relevant. > > This way you can act automatically using this information. > > Java: > /* > * $OVIRT_METADATA.COMPONENT=<string> > */ > or: > // $OVIRT_METADATA.COMPONENT=<string> > > Shell/python: > # $OVIRT_METADATA.COMPONENT=<string> > > Well, you get the idea... > > This signature will allow: > a. find . -type f | xargs grep '\$OVIRT_METADATA.COMPONENT=mycomponent' > b. Future automation within gerrit. > > Regards, > Alon > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
