Thanks for doing this Joey! This patch will end up saving a bunch of time in a way that isn't immediately obvious. Fortunately, the 'worst case' time for a build is still the same as the 'only case' previously.
Where you WILL see improvements: 1- "empty queue time"-- if you push a patch when the queue is empty, you'll likely see a +1/-1 from Jenkins in as little as 20 minutes! This is because the multiple builds will run on a large number of machines, rather than just 1:20 for a single one. 2- "time to error" -- If you push a build that has an error on one of our more fickle systems (Arduino/Unit-tests), there is a potential that the build for that one will happen sooner, rather than at the end of the build like it is now! This means you could likely get your '-1' faster! Additionally, even in times of heavy traffic, we won't have a couple of builds taking over all of the time, so there is a decent chance that at least 1 of your builds will make it to the front! 3- "when we get more hardware!" -- This solution scales much more efficiently, adding servers at LF will now result in quicker build times for everyone, not just the first X (where X==#of servers) into the queue. Where you WON'T see improvement: 1- In high-traffic situations where we have a large number of commits all going into gerrit at the same time, the builds will still stack up like before. I believe that there will be at least a better chance for commits to be at least partially validated sooner. What we can do to improve stuff further: 1- Always be mindful of what submissions might cost in build-time. A few changes have gone in that have been pretty expensive, perhaps see if anything sticks out 2- Add Servers! The more the merrier :) Thanks all -Erich On Wed, 2015-07-22 at 20:43 +0000, Morrow, Joseph L wrote: > All, > > > > Recently the Continuous Integration system (ie. Jenkins and associated > build scripts) were overhauled to bring down the build times. At its > worst, the builds were taking approximately 1 hour 40 minutes to > verify a changeset. The overhaul has brought verification times down > to just 25-30 minutes. Because of the nature of branching out a > sequential build process to a parallel build process in Jenkins, and > with our setup with Gerrit verifications, all pending work for master > will need to be rebased onto latest master. > > > > In most cases, the following commands will rebase your work locally > (you may replace ?<my_parent_branch>? with ?master? if you?re working > on top of master: > > > > Do this if you don?t already have a local branch for your work: > > git checkout ?b <my_branch_name> > > > > git checkout <my_parent_branch> > > git pull > > git checkout <my_branch_name> > > git rebase ?onto <my_parent_branch> HEAD^ > > > > Do this if you would like to update your Gerrit changeset with the > rebase: > > git push origin HEAD:refs/for/<my_parent_branch> > > > > Do this if you don?t keep local branches for your work (not advised): > > git branch ?D <my_branch_name> > > > > Alternatively, if your changeset is just on Gerrit and it is already > ready to be merged into master (and no new modifications need to be > made to your changeset), you may simply click on ?rebase? on the > dashboard webpage for your Gerrit Changeset. > > > > For general Git & Gerrit questions please refer to the IoTivity wiki, > or try researching via Google. > > > > Thanks, > > > > Joey Morrow > > > > > > > _______________________________________________ > iotivity-dev mailing list > iotivity-dev at lists.iotivity.org > https://lists.iotivity.org/mailman/listinfo/iotivity-dev
