Re: gitlab-ci-runner updates
On 2021-04-28 17:18:39, Dmitry Smirnov wrote:
> On Wednesday, 28 April 2021 5:35:34 AM AEST Antoine Beaupré wrote:
>> I was sorry to find out that gitlab-ci-runner didn't make it to bullseye
>
> No worries. Gitlab-runner, as a statically linked executable, is easy
> to install from "unstable". They also release often so we would not
> have obsolete release in "stable".
Yeah, that's what I did from buster, but I'm a little hesitant in
sourcing packages directly from unstable, because then there's no "event
horizon" when which the package becomes ... well, stable.
[...]
>> I am not exactly familiar with the workings of the package,
>
> I like simple workflow resembling the following:
>
> https://salsa.debian.org/onlyjob/notes/-/wikis/bp
It would be helpful to have a link to those notes (or a TL;DR:) in a
README.source in the source package...
>> so I did this so far:
>>
>> git checkout upstream
>> git checkout pristine-tar
>> git checkout master
>> gbp import-orig --uscan
>
> I wouldn't bother with any of that because you will have to do it multiple
> times while progressively removing components from "vendor" while
> accumulating garbage in the git repository.
Well that's what git reset is for. :)
> I had more to say about that workflow in general - you can find my
> notes here:
>
> https://salsa.debian.org/onlyjob/notes/-/wikis/no-gbp
Hum. That's a rather long read and I'm not sure I want to get into a
"how my way of building Debian packages is better than yours". It seems
we all have our ways and while that's unfortunate, I guess that's life.
The key point, in my mind, is that each package should explicitly
document its own workflow clearly somewhere, and that wasn't done in
this specific package. I looked at the existing branches from Salsa and
they *did* have the upstream/pristine-tar/master so I assumed gbp was
the right way to go forward. I'm happy to use another workflow.
>> That generated a supposedly stripped tarball, yet I got curious and
>> figured I would take a look at what was in there, particularly at the
>> juicy vendor/ directory:
>> ...
>> Holy crapamoly! Then I compared that with the previous tarball:
>> ...
>> Ah. So we already have 1000+ files in vendor/, and the 13.11 update
>> somewhat doubles that.
>
> You are starting to feel the pain... :) They do that with almost every
> major release. I even raised the bug with upstream once:
>
> https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3178
That's kind of trying to put the toothpaste back in the
tube... gitlab-runner is a golang project, that is going to just keep
happening, IMHO. :)
>> How do we decide what's okay and what's not in here? It's kind of a
>> laborious process to go through the diff...
>
> Typically I remove vendored components one by one, listing them in
> copyright/Files-Excluded (and replacing with packaged libraries),
> re-building package every time.
Right, that's what I figured.
> The process is usually more tedious than complex but sometimes there
> might be problems.
Definitely feels tedious. :)
>> Shouldn't we just remove *all* of vendor/?
>
> Ideally yes, but in practice we can not, at least not for the particular
> package. Portion of Kubernetes is and few micro-libraries are not
> provided by any package. Also there might be cases when Gitlab-Runner
> won't build with anything we have but a vendored loibrary.
Right, makes sense.
>> I understand this is a somewhat sensitive issue, especially considering
>> the recent Kubernetes discussions (which this is related to, because it
>> does ship kubernetes glue code)
>
> It hasn't been a sensitive issue until controversial ruling by CTTE.
> (To be honest I suspect there was unhealthy influence of a Kubernetes
> insider on the committee but whatever).
I am not sure I want to get into this debate, but I would argue that the
ruling would have been considered controversial regardless of the
outcome. :) (Also, I am not sure how productive it is to question the
neutrality of the CTTE in this bug report, so I would refrain from that
as well if I were you...)
> We have _many_ packages with no "vendor" or partial vendoring
> (e.g. syncthing, restic, consul, nomad, docker.io, libpod/podman
> and its components, vault, etc.). And those are only few heavy ones I
> could recall straight from my head. Heck, the most golang packages
> have some or all vendored components removed in favour of packaged
> libraries. That's just how we package Golang stuff.
Yep, I've done a few myself! It generally works okay outside of the
kubernetes world, because things are generally sane. ;)
[...]
> P.S. I already see that packaging 13.11.0 is going to be above average
> effort. There are new FTBFS issues, some patches don't apply, etc...
Yeah, for now I've switched to the upstream packages (in which I already
found a bug - they don't ship /var/lib/gitlab-runner), which is a shame,
but I really had to get this out the door and couldn't afford to run an
older version.
I hope my small amount of work will have been useful for you!
Maybe I should have opened a bug report instead, too?
Thanks!
a.
--
We will create a civilization of the Mind in Cyberspace. May it be
more humane and fair than the world your governments have made
before.
- John Perry Barlow
Reply to: