CI beyond sn-devel

[Andrew Bartlett]

On Sun, 2017-11-19 at 11:42 +0200, Alexander Bokovoy via samba-
technical wrote:
> On la, 18 marras 2017, Andrew Bartlett via samba-technical wrote:
> > 
> > I agree with the sentiment and goals, but I actually think we need to
> > move beyond (wrap) autobuild.  It can't scale beyond the host it runs
> > on, and we need to move to something less bespoke.  
> > 
> > Have a look at this: Homu integrates with github (which we don't use as
> > a primary platform as it is not free software), but does a lot of what
> > we need, specifically one-at-a-time rebase and test:
> > 
> > https://github.com/servo/homu
> > 
> > If we had something like that, hooked up to a gitlab and a cloud-hosted 
> > CI system such as gitabl-ci then we can test beyond just one OS
> > (indeed, one host), and reject commits that break FreeBSD, are
> > incompatible with Windows or fail the WSPP testsuite. 
> 
> We have a similar model with freeIPA: https://github.com/freeipa/freeipa-pr-ci/
>  - a master git repository is hosted at pagure.io
> 
>  - a commit hook updates github repository with force-push, making that
>    one a mirror
> 
>  - any pull request proposed against the github tree either by an
>    authorized person or having a label to run a test by an authorized
>    person triggers a pull request CI to run tests
> 
>  - these tests run on handlers that may be set up everywhere else; in
>    freeIPA case we have official PR CI running on a Red Hat internal
>    servers and on travis-ci infrastructure
> 
>  - once PR CI runs completed, their status is marked in the github pull
>    request
> 
>  - once pull request is ACKed by a human, the code from PR can be merged
>    to the master tree on pagure.io by a human. We use some scripts to
>    automate this process -- the script checks PR status, its PR CI
>    status, whether it can be applied by fast forward to a selected git
>    branch and also is able to open pull requests for backports
>    automatically
> 
> github is basically used in this scheme just to ease the process to
> provide pull requests for contributors and to visualize results of PR CI
> integration. The whole story starts with a git push to a remote place
> and marking this push as 'authorized for PR CI run', this is equivalent
> to 'git autobuild' in the current Samba Team practice. One can easily
> keep these models compatible because all it really requires to have is a
> place where git remotes are pushed and a way to mark those pushes as
> 'authorized'. A PR CI service could be pushed with builds coming from
> anywhere and 'git autobuild' can still be used as an entry point to push
> the changes.

Thanks for the description.  This is much of what I would like to get
out of integration with a web service.  CI across wintest, the MS
protocol testsuites, FreeBSD and autobuild needs more UI than autobuild
alone, so use hosted tools that do that well. 

I'm getting things set up on gitlab.com and I'll see what works from
there.  If things go really well, and we want to run our own gitlab, we
can export the working configurations, but as described above there
isn't any need for it to be the canonical repo. 

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba