Update to 8.1 stable release

[mallardduck]

Just noticed after doing this that there seems to be a bot that might be making this happen. So please disregard if it's just a matter of time for that to happen to get the 8.1 images updated to release.

[enumag]

It seems that in case of PHP 8.0 the RC -> stable transition was done manually here. So the bot likely doesn't support that case. Your PR should help. :-)

[enumag]

This might need to be adjusted, though I have no clue what this file is about.
https://github.com/docker-library/php/blob/master/generate-stackbrew-library.sh#L4-L7

[mallardduck]

good catch @enumag! that script seems to be for generating this file: https://github.com/docker-library/official-images/blob/master/library/php

I think I've updated it correctly

[sbuerk]

As 8.1 release missing until now - I'm not into it if this PR would really solve it, or if it is the full/right way. Anyway would be nice to have 8.1.0 released as images ready, as we depend on it for our testing.

Not sure who is maintainer on this repository, but looking through the commits maybe @yosifkit ?

[WyriHaximus]

@sbuerk It's the weekend, let the maintainers also enjoy the weekend how they prefer :). I get that you're excited and want an 8.1 stable image available as soon as possible. But generally, these images lag up to a week behind. Also IMHO it might make sense to have #1226 merged in first so we don't end up with a single outdated Alpine 3.13 image of 8.1.

[sbuerk]

@WyriHaximus Eh sry .. you are right. (Really it's weekend ?!) I should check my time feeling.
I'm sorry ...

[WyriHaximus]

@sbuerk Hey I get it, we're all tired, we all had our ability to sense time passing distorted, we're all excited about all the features 8.1 brings. The only thing I'm asking is to let maintainers take their rest when they want to without getting pinged, and I'm just assuming the weekend here 😅, so they can go in (well) rested and review PR's like these.

[sbuerk]

@WyriHaximus You are absolutly right, and reading my own post myself I'm feeling uncomfortable with it - and I'm regret it.

It was too pressing, so please take my apology.

Very gratefull for this repo and the pre-work. Just slipped in in a 5 min slot and "ping there" before going on with own work and so forth .. which is no excuse !!!

We are "green" wit RC6 , and in generelly it should not change much. Was quick shot. Hopefully you and the maintainer(s) can take the excuse.

[tianon]

Also IMHO it might make sense to have #1226 merged in first so we don't end up with a single outdated Alpine 3.13 image of 8.1.

Agreed -- I've merged #1226 now (and plan to rebase this after I get through more long Thanksgiving weekend email backlog, if @mallardduck doesn't beat me to it 😇 ❤️).

[mallardduck]

@tianon - i'll get the rebase done RN

[tianon]

Nice, thanks! 👍

[martinssipenko]

Am I missing something or what but looks like the images with Alpine 3.15 are missing linux/386 and linux/amd64 OS/ARCH type images.

[martinssipenko]

Never mind, I have jumped the gun, looks like the images are still building at the time of writing this comment.

https://doi-janky.infosiftr.net/job/multiarch/job/amd64/job/php/

[enumag]

Is there some way to change the pipelines to build the amd64 and 386 images first? 🤔 It makes no sense that it's starting from the least needed images.

[pherum]

 => [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 908B 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> ERROR [internal] load metadata for docker.io/library/php:8.1-cli-alpine 2.3s
=> [auth] library/php:pull token for registry-1.docker.io 0.0s
------
> [internal] load metadata for docker.io/library/php:8.1-cli-alpine:
------
failed to solve with frontend dockerfile.v0: failed to create LLB definition: no match for platform in manifest sha256:bdf54663bba260b7f61b79dd605b9f17e8a5c3b3765d273a9fcb637cb8930050: not found

[martinssipenko]

@pherum please see comments #1227 (comment) and #1227 (comment).

[WyriHaximus]

Is there some way to change the pipelines to build the amd64 and 386 images first? thinking It makes no sense that it's starting from the least needed images.

@enumag This only happens for the first image of a new minor/major. Honestly, I really doubt changing all that is worth the ~8 hours you get to use the new major/minor earlier once per year.

[tianon]

Each architecture queue is completely independent -- other amd64/i386 builds are what delay amd64/i386 builds (we don't ever have an amd64 build waiting for a mips64le build, for example).