[Vm-dev] the purpose of CI

Jakob Reschke jakob.reschke at student.hpi.de
Mon May 29 21:10:57 UTC 2017


2017-05-29 21:25 GMT+02:00 Eliot Miranda <eliot.miranda at gmail.com>:
>  Hi Ben,
>
> On Sun, May 28, 2017 at 6:46 AM, Ben Coman <btc at openinworld.com> wrote:
>>
>>
>>
>> Maybe I'm speaking out of turn from the sidelines, but just curious to ask
>> a leading question...
>>
>> What is the purpose of the Continuous Integration system?
>>
>
> One thing for me is to identify when I've made a mistake  Yes it is selfish
> of me to want to break a build, but in some way those of us who are active
> VM developers must be able to commit and see what fails, especially when we
> have a large platform and VM variant spread.
>
> IMO what needs to be added is a way of marking commits as good.  I think we
> should continue to be allowed to break the build (something we do
> unintentionally).  But we need a set of criteria to mark a build as fit for
> release and have a download URL from which we obtain the latest releasable
> VM.

Travis can be configured to build all branches, so the continuous test
feedback is not a show-stopper for working on feature branches. Since
by default the result notifications only go to the committer (and
author), nobody should be offended if the allowed failures list
differs from branch to branch.

Marking commits as good can either be done by tagging them, or by
merging/picking good changes back to a "production" branch (usually
master, here Cog, probably) as early as possible. Pull requests have
the added bonus that the changes are tested by Travis both before and
after the (anticipated) merge, so you see a color before pushing the
button.

Selecting "good" commits automatically and performing some git
operations on them should also be possible with after_success scripts:
https://gist.github.com/bumi/5824548 We even already have one that
uploads to bintray. This also needs not be the same for all branches.

Since everyone with a GitHub account can also enable Travis for their
own repositories, even working on forks and requesting pulls from
there into the official repository should be viable, as far as Travis
is concerned.

So it seems to me that all that is needed is to agree on a workflow
and branch organization, the CI can be programmed accordingly.

Best,
Jakob


More information about the Vm-dev mailing list