I have spent the last two weeks on a different approach to our CI setup, published the current version of the tools just now and added a document to our website (not linked from the main page yet until I have some feedback).
Please have a look at https://pkg-go.alioth.debian.org/ci.html, especially the first section (motivation/goals) and the last section (implications/caveats). tl;dr: the new approach allows for rebuilding the entire archive (!) in about 1 minute (!) (longer for changes triggering rebuilds/tests of more/more expensive packages, of course), but will require a few changes in a small handful of our packages. Curious to hear your thoughts, On Tue, Jan 30, 2018 at 6:05 PM, Michael Stapelberg <[email protected]> wrote: > Status update: I now ran ci.go, i.e. all of our repositories should now be > configured. > > The next step is to bulk-commit debian/gitlab-ci.yml. I’ll let you know > more details once I start working on that. > > On Tue, Jan 30, 2018 at 2:38 PM, Michael Stapelberg <[email protected] > > wrote: > >> >> >> On Tue, Jan 30, 2018 at 2:17 AM, Alexandre Viau <[email protected]> wrote: >> >>> This is great! Good job. >>> >> >> Thanks for the feedback :) >> >> >>> >>> > Aside from the GitLab-side, we also need a .gitlab-ci.yml file >>> > in the repository itself. I can bulk-commit these, along with >>> > adding them to Files-Excluded in debian/copyright so that >>> > upstream copies are discarded. >>> >>> Please do. (it looks like the d/copyright thing won't be needed if you >>> can change the path to debian/gitlab-ci) >>> >> >> Indeed. >> >> >>> >>> > I suggest setting this path to “debian/gitlab-ci.yml” for our >>> > repositories, so that we don’t need to mangle upstream’s >>> > .gitlab-ci.yml and have all relevant files within the debian/ >>> >>> +1 >>> >>> On 2018-01-28 09:35 AM, Michael Stapelberg wrote: >>> > On Sat, Jan 27, 2018 at 11:21 PM, Michael Stapelberg >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > With this feature place, the next step I’d like to implement is >>> > a speculative package auto-updater: upon noticing the Debian >>> and >>> > upstream version have diverged, we could import the new >>> version, >>> > send a Merge Request, have the CI check for breakages and >>> > (manually) merge and upload if no breakages are introduced. >>> >>> >>> That would be great. >>> >>> Did you see the recent devscripts commit? #811565[1] was marked as >>> pending. >>> >> >> I saw it, but thanks for the pointer :) >> >> >>> >>> We will be ale to use uscan to watch for new upstream versions. The tool >>> you are building could make use of this. >>> >>> >>> Maybe you want to contribute to this script: >>> - >>> https://salsa.debian.org/pkg-go-team/migrate-pkg-go-to-salsa >>> /blob/master/configure-all-projects.py >>> >>> It protects branches and create webhooks on all repositories in the >>> "packages" subgroup on salsa. We should add the debian/gitlab-ci.yml >>> config too so that we can just run the script and have all salsa >>> projects configured uniformly. >>> >> >> The ci tool which I linked to also applies to all repositories. We should >> definitely join forces here. I’d prefer tooling to be written in Go, >> because I’m much more familiar with it. Would you be okay with merging >> configure-all-projects.py into ci.go? I’d be happy to review. If you don’t >> have the time, I could also contribute the necessary changes. >> >> >>> >>> By the way, don't forget to update dh-make-golang too, so that new >>> repositories have the setting. >>> >> >> Will do. I wanted to update it to be consistent with ci.go anyway. >> >> >>> >>> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811565 >>> >>> >>> Cheers, >>> >>> -- >>> Alexandre Viau >>> [email protected] >>> >>> >> >> >> -- >> Best regards, >> Michael >> > > > > -- > Best regards, > Michael > -- Best regards, Michael
_______________________________________________ Pkg-go-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
