2017-05-29 21:25 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Ben,
On Sun, May 28, 2017 at 6:46 AM, Ben Coman btc@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
vm-dev@lists.squeakfoundation.org