----- Original Message ----- > From: "Yair Zaslavsky" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Eyal Edri" <[email protected]>, "engine-devel" <[email protected]>, > "infra" <[email protected]> > Sent: Tuesday, July 9, 2013 3:42:24 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > commits > > > > ----- 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.
I don't care how this is to be called. However, I do not think that commit message is the place for instructing CI to do anything. Commit message stays for good, it should contain information that is required a year from now. It has nothing to do with tests and such. > > > > 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? Drop the maintainer, it is a suggestion of extra metadata we can add to automatically CC relevant people. Add more metadata, so that every change in that file will trigger specific tests. > > > 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
