Allow user to set build.image: testing in the config file
#6676
Conversation
|
Believe @agjohnson had some reservations about letting users set this "forever". I think I'm +0 on it, so that users can opt into a new image without having to pester us to setup a feature flag -- I think it will lead to less support over time than folks who have broken builds because of testing, but not sure. |
|
Yeah, a bit. I worry users are opting in to an image that solves a problem they are having, where the testing image is much more of a beta test area for us. I'd much rather we increase release cycles and tell the user "use X image when it's released, which won't be long", not "become a beta tester for our docker images". |
There was a problem hiding this comment.
Changes look good, and I'm solidly on the fence on needing a testing image in general. It feels like heading in the opposite direction from shortening release cycles on the image. However, our issues here are coming from the python3.8 upgrade, and this has introduced significant friction to docker image releases. It seems we have to keep more images around as python3.8 was a significant upgrade. I think switching our docker image release pattern from semver is probably the ultimate answer here, so I'm okay with a change like this in the interim
We have a new
testingimage now that we can recommend to users when they need something extra that it's now in our current image, but will be available in the following image.This allow us to not have to do work manually (like modifying
container_imagein the db), clearly communicate to the user that they are using something that it's not released yet and also allow them to opt-in/out when they want.