[pkg-go] GitLab CI: git-buildpackage and ratt

[Michael Stapelberg]

Status update:

I have updated the ci setup tool to create/update debian/gitlab-ci.yml:
https://salsa.debian.org/go-team/ci/commits/master

I ran this yesterday and had it do a CI run for all of our repositories.
There were 3 failures, all of which because the repository in question has
a debian/changelog entry whose version git-buildpackage cannot find as a
tag:

https://salsa.debian.org/go-team/packages/golang-github-
armon-go-socks5/-/jobs/8311
https://salsa.debian.org/go-team/packages/golang-github-
opencontainers-go-digest/-/jobs/8323
https://salsa.debian.org/go-team/packages/golang-github-
opencontainers-specs/-/jobs/8466

Aside from that, things look good, so I’m running the ci tool periodically
(every hour) to configure newly created repositories appropriately.
Longer-term, I’ll need to think about how to best integrate it with
repository creation via dh-make-golang: putting the code into
dh-make-golang itself might not be the best idea. We’ve seen people use old
versions in the past, so there is a chance we’ll get unexpected differences
in how our repositories are set up.

Regarding the CI itself, after pushing your changes to the master (or
debian/*) branch, the Debian archive will be built, your changes will be
applied, and the archive will be built again. Any new issues will be
reported. This takes approximately a minute or two, so I would recommend to
wait for the CI results before uploading to Debian.

Please let me know if you find any issues!

On Tue, Feb 20, 2018 at 8:02 PM, Martín Ferrari <tincho at tincho.org> wrote:

> On 20/02/18 12:20, Michael Stapelberg wrote:
>
> > I’m only aware of one package (jacobsa/crypto) which has a
> > Debian-specific patch that requires the use of an architecture-specific
> > build tag. My proposed solution for this is to either specify the
> > architectures (as opposed to custom pointer size build tags) in the
> > files (they change rarely enough), or at least add the amd64
> architecture.
> >
> > Are you aware of other packages which use the same technique? If so, it
> > might be good to write up a little bit of documentation, and perhaps
> > even make this a feature of dh-golang.
>
> the ones I have in mind would work for amd64 without the tags. Others
> could be patched. The one that is not going to be easy without a lot of
> medding is x/sys.
>
> > This particular example is moot since dh-golang 1.31’s
> > install-testdata-by-default change :).
>
> Cool
>
> > I understand your concern. I suggest we try my suggested approach and
> > re-evaluate at some point down the road (a quarter? a year?) whether
> > keeping it up is feasible and worthwhile. We can always course-correct,
> > there’s no lock-in here.
>
> Sounds good to me.
>
> --
> Martín Ferrari (Tincho)
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20180225/ffa1d43e/attachment-0001.html>