On Friday, 29 January 2016, Lalatendu Mohanty <[email protected]> wrote:
> On 01/29/2016 10:17 AM, Pradeepto Bhattacharya wrote: > >> Hi, >> >> >> ----- Original Message ----- >> From: "Dharmit Shah" <[email protected]> >> To: [email protected] >> Sent: Thursday, January 28, 2016 6:50:22 PM >> Subject: [Container-tools] CI for ADB >> >> 6. Also, every merge in the master branch of ADB will trigger a test of >> one >> example for different provider as mentioned in point 3. This won't involve >> building ADB from its Kickstart file. Latest ADB build will be used for >> the >> purpose. >> >> >> Instead of building post-merge, it can/should be built per PR. I believe, >> we are using GitHub and Jenkins in which case we are covered by an >> excellent plugin [0]. >> >> I have used it previously to a good effect in a project. Back then, we >> put in some checks like unit tests, Pylint etc that would run on very new >> PR and every new push to an existing PR. That way, the developer code >> review only happened when the plug-in gave a green signal and thus saved a >> lot of developer time. >> >> IIRC, the plug-in clones the master and then pulls in the changes from >> the PR and after that the CI system is free to build, run tests etc or >> whatever it is configured to do. >> >> Having said that, I would like to add two points - 1) if we can't use >> the plug-in for some reason like we can't add it to Jenkins or something >> else, I believe we could still replicate the idea by doing the Git >> operations mentioned above ourselves in our pipeline code. 2) This is not >> to say that we shouldn't test post merge, we definitely should run tests >> and whatever is required once merge is done. >> >> [0] >> https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin >> >> Please let me know if you have any questions. >> >> Regards, >> >> Pradeepto >> > > I agree with you. Also as Dharmit mentioned later in the thread, we are > planning to do that. However one thing we are not doing is the rebuilding > of the Vagrant box for each PR because building the vagrant box is an > expensive affair at this point of time. It takes lot of time (i.e. more > than 1 hour). In future if we can reduce the build time then we should > rebuild the Vagrant box for each PR applicable to the box. > I would encourage you to do a full build every PR, and focus on this instead of nightlies. This is where the "nirvana" of DevOps is for a developer. You get better commitment on the code changes someone makes * full confidence for the developer on whether your change worked or not - makes it easier to commit to your code * a master branch you can always be confident in - if there is a break it's a problem with the tests not the developer * a much easier getting started experience for a new contributor - you can be confident your code works as opposed to guessing how to run the tests I understand the downside - the time impact. However, if you don't put this process in place now, the incentive to address the time (a long build time is a productivity problem in itself) or capacity issue (e.g. lack of hardware to run the jobs), you'll always find an excuse to put off doing it later. I've been through this 4 or 5 times now, and it's always been most successful when we put the right process in place upfront and then handle the impact. > > -Lala > >> >> _______________________________________________ >> Container-tools mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/container-tools >> > > _______________________________________________ > Container-tools mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/container-tools >
_______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
