On Tue, Feb 21, 2023 at 06:01:19PM +0000, Andrew Cooper wrote:
> On 21/02/2023 5:59 pm, Andrew Cooper wrote:
> > On 21/02/2023 4:55 pm, Anthony PERARD wrote:
> >> Jessie as rearch EOL in 2020.
> >>
> >> Even if we update the containers, we would still not be able to reach
> >> HTTPS webside with Let's Encrypt certificates and thus would need more
> >> change to the container.
> >>
> >> Signed-off-by: Anthony PERARD <anthony.per...@citrix.com>
> > How is this interact with the other patches in the series?
> >
> > I presume we do want to take patch 4 and rebuild the containers, for the
> > older branches. And that's fine.
> >
> > And IMO we should be dropping jessie testing, so this is almost fine for
> > staging.
> >
> > Except, jessie-32 is the only x86-32 build test we've got, so I think we
> > want to replace it with a newer container before dropping the jessie*.
Actually, we have two mores: debian-unstable-32-* and
debian-stretch-32-*. So an old distrib and a very new. So there's
probably no need to add more.
> Further to this, I really don't think we need to have a 4-wide matrix of
> {clang,gcc}{debug,release} for just a 32bit tools userspace. Debug
> clang+gcc will do, and save on some testing cycles.
I guess we could remove debian-{stretch,unstable}-32-{clang,gcc}. I'll
add a patch for that.
> ~Andrew
>
> >
> >> ---
> >> Notes:
> >> HTTPS would fail unless we commit "automation: Remove expired root
> >> certificates used to be used by let's encrypt", that is. Patch still in
> >> the series, and fix Jessie.
> > If we're dropping the jessie containers, do we really need that change
> > too? Because we really shouldn't be playing around with URLs on older
> > branches.
No, there's no need to change it. It's just a bit confusing to both
update and delete. In the patch that remove the debian-jessie jobs, I
kind of want to also remove the dockerfile, but if the dockerfile is
updated in the series it is weird to remove it in that same series.
Thanks,
--
Anthony PERARD
