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

[Martín Ferrari]

On 04/03/18 21:39, Michael Stapelberg wrote:
> Ah! Runs will automatically be triggered as soon as a gitlab-ci.yml file
> is found. You can retry any run with the “retry” button next at the top
> right. See for
> example https://salsa.debian.org/go-team/packages/ethflux/-/jobs/8312
> 
> Does that answer your question?
Ah, that's perfect. Thanks!

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

On Sun, Mar 4, 2018 at 6:29 PM, Martín Ferrari  wrote:

> Hi,
>
> Thanks for all the info, now it is a lot more clear!
>

Great! I updated ci.html with the link as discussed.


>
>
> On 04/03/18 08:48, Michael Stapelberg wrote:
> > * What kind of control do we have over it?
>
> > Not sure I follow. Can you make this question more specific?
>
> Wondering about if it is posible to manually trigger runs, re-tries, etc.
>

Ah! Runs will automatically be triggered as soon as a gitlab-ci.yml file is
found. You can retry any run with the “retry” button next at the top right.
See for example
https://salsa.debian.org/go-team/packages/ethflux/-/jobs/8312

Does that answer your question?


>
>
> --
> Martín Ferrari (Tincho)
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

Hi,

Thanks for all the info, now it is a lot more clear!


On 04/03/18 08:48, Michael Stapelberg wrote:
> * What kind of control do we have over it?

> Not sure I follow. Can you make this question more specific?

Wondering about if it is posible to manually trigger runs, re-tries, etc.


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

On Thu, Mar 1, 2018 at 2:41 PM, Martín Ferrari  wrote:

> On 01/03/18 07:58, Michael Stapelberg wrote:
> > I’m assuming you have read https://pkg-go.alioth.debian.org/ci.html
> > already. If not, start there.
>
> I had read it, but it was good to read it again.
>
> > Instead of sharing the knowledge only on mailing list posts, I would
> > strongly prefer to extend ci.html such that it makes sense to everyone
> > and is easily discoverable.
> >
> > Could you pose a few specific questions, which I’ll try to answer
> > through updates of ci.html? Thanks!
>
> I think the problem is that I don't know anything about Gitlab and its
> CI infrastructure.. My main questions would be:
>

Thanks for the feedback. Have a look at
https://docs.gitlab.com/ce/ci/quick_start/README.html please (I’ll add the
link to ci.html).


>
> * Where does all this run?
>

The runner we’re using is installed on a machine at my place. I assume that
as salsa usage grows, more shared runners (run by DSA/the salsa team?) will
become available, and we can just switch our workload over to them. For the
time being, using our own runner is a nice way to not step on anyone’s toes
and ensure our resource usage doesn’t hurt anyone else. IIUC, the current
shared runners should only be used for GitLab pages and the like.


> * How does it communicate with gitlab?
>

https://forum.gitlab.com/t/how-does-communicate-gitlab-runners/7553


> * What kind of control do we have over it?
>

Not sure I follow. Can you make this question more specific?


>
> Sorry for the very basic questions..
>
> --
> Martín Ferrari (Tincho)
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

On 01/03/18 07:58, Michael Stapelberg wrote:
> I’m assuming you have read https://pkg-go.alioth.debian.org/ci.html
> already. If not, start there.

I had read it, but it was good to read it again.

> Instead of sharing the knowledge only on mailing list posts, I would
> strongly prefer to extend ci.html such that it makes sense to everyone
> and is easily discoverable.
> 
> Could you pose a few specific questions, which I’ll try to answer
> through updates of ci.html? Thanks!

I think the problem is that I don't know anything about Gitlab and its
CI infrastructure.. My main questions would be:

* Where does all this run?
* How does it communicate with gitlab?
* What kind of control do we have over it?

Sorry for the very basic questions..

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

I’m assuming you have read https://pkg-go.alioth.debian.org/ci.html
already. If not, start there.

Instead of sharing the knowledge only on mailing list posts, I would
strongly prefer to extend ci.html such that it makes sense to everyone and
is easily discoverable.

Could you pose a few specific questions, which I’ll try to answer through
updates of ci.html? Thanks!

On Wed, Feb 28, 2018 at 10:01 PM, Martín Ferrari  wrote:

> Michael,
>
> On 25/02/18 22:43, Michael Stapelberg wrote:
>
> > 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:
>
> This all looks great, thanks a lot!
>
> Now, I am still a bit confused as to how this all works :-) Could you
> share a basic intro?
>
> --
> Martín Ferrari (Tincho)
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

Michael,

On 25/02/18 22:43, Michael Stapelberg wrote:

> 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:

This all looks great, thanks a lot!

Now, I am still a bit confused as to how this all works :-) Could you
share a basic intro?

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [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  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
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

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)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

On Tue, Feb 20, 2018 at 12:06 PM, Martín Ferrari  wrote:

> Hi,
>
> On 19/02/18 17:13, Michael Stapelberg wrote:
>
> > I see the role of the CI setup as complementary: I expect that people
> > will still build packages locally as they work on the packages. That
> > path will continue to cover the debian/* part of the package. The
> > remainder (fit into the archive) will be covered by the CI. In the worst
> > case, the issue will be caught on the buildds (provided one uses
> > source-only uploads).
>
> OK, good point.
>
> > Regarding the amount of work required to make packages buildable
> > directly with the Go tool, have a look at the examples I listed at the
> > bottom of the document. I don’t expect to spend more than 15 minutes per
> > package, and I can volunteer to do the initial fixes. We need to be on
> > the same page regarding the longer-term strategy, though, otherwise
> > packages will degrade quickly.
> >
> > Does that address your concern?
>
> More or less, there are things that would be very clumsy to do without a
> Makefile. For example, arch-specific build tags, if you don't evaluate
> the complete makefile you won't get those. Granted, if you are only
> using amd64 this would be a non-issue most of the time, although you
>

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.


> have things like this that will still require evaluating properly
> debian/rules:
>
> export DH_GOLANG_INSTALL_EXTRA := godoc/static \
> $(wildcard */*/testdata) $(wildcard */*/*/testdata)
>

This particular example is moot since dh-golang 1.31’s
install-testdata-by-default change :).


>
> Dunno, seems it could work as you propose it, but at the same time I am
> a bit worried that we will need to be careful not to break the system,
> and that it will not be obvious when building locally.
>

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.

-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

Hi,

On 19/02/18 17:13, Michael Stapelberg wrote:

> I see the role of the CI setup as complementary: I expect that people
> will still build packages locally as they work on the packages. That
> path will continue to cover the debian/* part of the package. The
> remainder (fit into the archive) will be covered by the CI. In the worst
> case, the issue will be caught on the buildds (provided one uses
> source-only uploads).

OK, good point.

> Regarding the amount of work required to make packages buildable
> directly with the Go tool, have a look at the examples I listed at the
> bottom of the document. I don’t expect to spend more than 15 minutes per
> package, and I can volunteer to do the initial fixes. We need to be on
> the same page regarding the longer-term strategy, though, otherwise
> packages will degrade quickly.
> 
> Does that address your concern?

More or less, there are things that would be very clumsy to do without a
Makefile. For example, arch-specific build tags, if you don't evaluate
the complete makefile you won't get those. Granted, if you are only
using amd64 this would be a non-issue most of the time, although you
have things like this that will still require evaluating properly
debian/rules:

export DH_GOLANG_INSTALL_EXTRA := godoc/static \
$(wildcard */*/testdata) $(wildcard */*/*/testdata)

Dunno, seems it could work as you propose it, but at the same time I am
a bit worried that we will need to be careful not to break the system,
and that it will not be obvious when building locally.

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

Thanks for taking a look.

I see the role of the CI setup as complementary: I expect that people will
still build packages locally as they work on the packages. That path will
continue to cover the debian/* part of the package. The remainder (fit into
the archive) will be covered by the CI. In the worst case, the issue will
be caught on the buildds (provided one uses source-only uploads).

Regarding the amount of work required to make packages buildable directly
with the Go tool, have a look at the examples I listed at the bottom of the
document. I don’t expect to spend more than 15 minutes per package, and I
can volunteer to do the initial fixes. We need to be on the same page
regarding the longer-term strategy, though, otherwise packages will degrade
quickly.

Does that address your concern?

On Mon, Feb 19, 2018 at 3:56 PM, Martín Ferrari  wrote:

> Michael,
>
> On 19/02/18 09:25, Michael Stapelberg wrote:
> > 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).
> This is a great initiative, thanks!
>
> Now, my main objection is to using the go tool directly and skipping the
> debian build system. I understand this is faster, but it also means that
> we could be missing problems in the debian files themselves, and that
> some packages will either fail or require a lot of work to avoid having
> any customisation in debian/rules.
>
>
> --
> Martín Ferrari (Tincho)
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Martín Ferrari]

Michael,

On 19/02/18 09:25, Michael Stapelberg wrote:
> 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).
This is a great initiative, thanks!

Now, my main objection is to using the go tool directly and skipping the
debian build system. I understand this is faster, but it also means that
we could be missing problems in the debian files themselves, and that
some packages will either fail or require a lot of work to avoid having
any customisation in debian/rules.


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

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 
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  > wrote:
>
>>
>>
>> On Tue, Jan 30, 2018 at 2:17 AM, Alexandre Viau  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
>>> > > 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
>>> av...@debian.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Michael
>>
>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

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 
wrote:

>
>
> On Tue, Jan 30, 2018 at 2:17 AM, Alexandre Viau  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
>> > > 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
>> av...@debian.org
>>
>>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

On Tue, Jan 30, 2018 at 2:17 AM, Alexandre Viau  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
> > > 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
> av...@debian.org
>
>


-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Alexandre Viau]

This is great! Good job.

> 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)

> 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
> > 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.

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.

By the way, don't forget to update dh-make-golang too, so that new
repositories have the setting.

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811565


Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

The tool to configure our repositories now lives at
https://salsa.debian.org/pkg-go-team/ci/blob/master/cmd/ci/ci.go.

I’ll run this tomorrow unless there are any objections.
For the time being, the tool only touches the runner configuration and CI
config path.
In other words, I will not yet place a debian/gitlab-ci.yml file in each
repository, so that we have some more time to gather feedback.

On Sun, Jan 28, 2018 at 1:44 PM, Michael Stapelberg 
wrote:

>
>
> On Sat, Jan 27, 2018 at 11:21 PM, Michael Stapelberg <
> stapelb...@debian.org> wrote:
>
>> Hey,
>>
>> Have a look at https://salsa.debian.org/stapelberg/toxiproxy/-/jobs/5260
>> — I just got a GitLab CI runner and job working which builds the package
>> using git-buildpackage, then looks for failures in reverse-dependencies
>> using https://github.com/Debian/ratt.
>>
>> I intend to write a tool to programmatically bulk-update CI settings on
>> GitLab, so that we can enable this feature for all of our repositories.
>>
>> 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.
>>
>
> I just saw that one can customize the path to .gitlab-ci.yml:
> https://docs.gitlab.com/ee/user/project/pipelines/settings.html#
> custom-ci-config-path
>
> 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/ directory.
>
>
>>
>> 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.
>>
>> Let me know if you have any thoughts,
>>
>> --
>> Best regards,
>> Michael
>>
>
>
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

On Sat, Jan 27, 2018 at 11:21 PM, Michael Stapelberg 
wrote:

> Hey,
>
> Have a look at https://salsa.debian.org/stapelberg/toxiproxy/-/jobs/5260
> — I just got a GitLab CI runner and job working which builds the package
> using git-buildpackage, then looks for failures in reverse-dependencies
> using https://github.com/Debian/ratt.
>
> I intend to write a tool to programmatically bulk-update CI settings on
> GitLab, so that we can enable this feature for all of our repositories.
>
> 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.
>

I just saw that one can customize the path to .gitlab-ci.yml:
https://docs.gitlab.com/ee/user/project/pipelines/settings.html#custom-ci-config-path

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/ directory.


>
> 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.
>
> Let me know if you have any thoughts,
>
> --
> Best regards,
> Michael
>



-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

[Michael Stapelberg]

Hey,

Have a look at https://salsa.debian.org/stapelberg/toxiproxy/-/jobs/5260 —
I just got a GitLab CI runner and job working which builds the package
using git-buildpackage, then looks for failures in reverse-dependencies
using https://github.com/Debian/ratt.

I intend to write a tool to programmatically bulk-update CI settings on
GitLab, so that we can enable this feature for all of our repositories.

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.

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.

Let me know if you have any thoughts,

-- 
Best regards,
Michael
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers