now that gerrit was upgraded to 2.6.1 this becomes much more easier with custom fields options.[1]
[1] http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.6.html "The patch set review screen can include radio buttons for custom labels if enabled by submit rules. ". ----- Original Message ----- > From: "Antoni Segura Puimedon" <[email protected]> > To: "infra" <[email protected]> > Cc: "engine-devel" <[email protected]> > Sent: Tuesday, July 9, 2013 12:41:45 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > commits > > I like the idea of having a label in the bottom part of the commit that is: > > METADATA: network > > which would be your second proposal. > > ----- Original Message ----- > > From: "Eyal Edri" <[email protected]> > > To: "engine-devel" <[email protected]> > > Cc: "infra" <[email protected]> > > 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Infra mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/infra > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
