Re: salsa CI
Philip Hands, le mar. 23 janv. 2024 17:52:57 +0100, a ecrit:
> Samuel Thibault <sthibault@debian.org> writes:
>
> > Philip Hands, le mar. 23 janv. 2024 16:27:12 +0100, a ecrit:
> >> Samuel Thibault <sthibault@debian.org> writes:
> >>
> >> > Hello,
> >> >
> >> > The CI on salsa doesn't manage to build the debian-installer package
> >> > because the signed linux 6.6.13 package is not available yet.
> >>
> >> Is the thing you want to:
> >> a) be able to build d-i on salsa even when we're in version skew,
> >> or
> >> b) do you want to be able to test with the latest version, whether it is signed or not?
> >
> > b)
> >
> > Normally the bump in debian-installer comes about the same time as the
> > linux upload. But there is the period between the linux upload and the
> > linux-signed upload during which we don't really know whether we want to
> > bump or not. Adding the alternative between non-signed and signed as I
> > proposed would allow to be fine with either, while making sure it's the
> > signed version which is used on buildds.
>
> Ah, fair enough.
>
> I guess in that case I'll need to adjust what I'm doing to detect the
> available versions of kernel that I'm looking for in that patch.
>
> If you're only worried about builds on salsa-CI, same approach as used
> in my MR ought to work,
Indeed.
It however doesn't fix the build on my laptop without some change :)
> and then one could perhaps control which kernel
> is selected via variables, or perhaps defaulting to the unsigned kernel
> (if available) would work for my use-case too, in which case I could
> just add that as a feature.
>
> The MR's here BTW: https://deb.li/3hHY2
>
> BTW would it actually cause you a problem for the build to work, despite
> the kernel being unavailable (e.g. by falling back to the previous
> version)?
For me it's fine for CI to fall back to the previous kernel for most
jobs of the pipeline. I guess we'd still want a build job in the
pipeline that sticks with the requested version, so that we notice in
case that's not working, without breaking the entire CI pipeline.
Samuel
Reply to: