[Container-tools] CI for ADB

[Pete Muir]

On Friday, 29 January 2016, Lalatendu Mohanty <lmohanty at redhat.com> wrote:

> On 01/29/2016 10:17 AM, Pradeepto Bhattacharya wrote:
>
>> Hi,
>>
>>
>> ----- Original Message -----
>> From: "Dharmit Shah" <dshah at redhat.com>
>> To: container-tools at redhat.com
>> 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
>> Container-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/container-tools
>>
>
> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20160201/1d5d0fe1/attachment.htm>