Hi Thomas
I don't see how your response relates to my original question. This is
the second time in a short while you decided to work this way.
On Sun, Sep 01, 2019 at 04:21:23PM +0200, Thomas Goirand wrote:
> If I understand well, you're moving ahead with having all done by the
> Salsa CI. That's really not what I envisioned. I though we'd be moving
> to build things on Casulana, at the same time as the ISO images.
I can't read your mind. You need to actually state them.
> The Salsa CI usually runs on Google cloud. We of course have less trust
> in that, than a Debian machine. It's also very slow, and not in sync
> with the Debian release process, which would make a lot more sense
> compared to the current daily build.
No. The CI core runs within the main GitLab instance on
goddard.debian.org. There is no Google involved.
The only thing that runs on Google is a shared CI runner that everyone
can use. However no-one needs to use it and instead can provide their
own runner. This is what we do for the cloud stuff.
> As a cloud user, I very much prefer to have images when needed, compared
> to a daily build for which I'm not sure I need an update. I'd see moving
> to that, instead of the perfect process Steve has implemented, as a
> regression.
I don't know what you mean. The archive changes four times a day. If
you think this is wrong, please actually propose changes.
> Your thoughts?
Nothing, as this does not relate to my original question.
Bastian
--
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2
Last time this was discussed the logic was thus:
1. Machine image builds must run on casulana because no other hardware (for instance an ephemeral gcloud instance) is trustworthy enough to do it
2. Machine image builds require a gitlab runner with elevated permissions (perhaps an ssh runner rather than a docker runner) due to technical reasons
3. Having a gitlab runner with elevated permissions on casulana is a security risk
4. Therefore machine image builds can not take place in gitlab ci