gateway

gateway copied to clipboard

A more accurate regex for tag is better. Sometimes the sha will start with v too

@Xunzhuo good point... agreed, detection would need to be more specific than a letter prefix.

I'm looking at how this could be implemented and not sure how we can detect the tag given how the release works. Currently it's just copying the docker image: https://github.com/envoyproxy/gateway/actions/runs/8154910922/job/22289300255#step:5:1

Since the image envoyproxy/gateway-dev:<sha> is copied to envoyproxy/gateway:<tag> the ld flag is going to be the <sha> from the build pipeline:

$ docker run --rm envoyproxy/gateway:v1.0.0-rc.1 version
ENVOY_GATEWAY_VERSION: v1.0.0-rc.1
ENVOY_PROXY_VERSION: distroless-v1.29-latest
GATEWAYAPI_VERSION: v1.0.0
SHUTDOWN_MANAGER_VERSION: 7d48480
GIT_COMMIT_ID: 7d48480fed10100a699ac360b2e1ace6eb49deab

ENVOY_GATEWAY_VERSION is set to the release based on what's in the VERSION file, but this won't work for SHUTDOWN_MANAGER_VERSION which needs to match the current build so the right image will be used in e2e tests.

Nothing immediately stands out as a simple and clean way of solving this without changing how the image is released so the ld flags can be set accordingly.

oh fun, thanks for pointing this out the fact that we dont rebuild a image when releasing, but instead promote a image (retag it), makes this chicken egg situation worse (gateway image defining a gateway image)

Originally posted by @arkodg in https://github.com/envoyproxy/gateway/issues/2789#issuecomment-1981587689

From a correctness perspective envoyproxy/gateway:v1.0.0-rc.1 is the same as envoyproxy/gateway-dev:7d48480

but this is an extra image dependency that should not be required

When releasing a image, we retag a image without rebuilding it, but the SHUTDOWN_MANAGER_VERSION is computed using a build time ld flag, which is causing this inconsistency

Also we should not pin shutdownmanager's version with EG.

A easier way, how about just using a more specific regex to match vx.x.x to determine if this is a release tag?

Obviously the sha doesn't have dot in it.

How does istio manage the istio-proxy version when releasing @zirain ?

How does istio manage the istio-proxy version when releasing @zirain ?

istiod release everything with a new tag, even there's nothing change(usually not happen). For samples, someone release it manually when necessary.

+1 on this, dev deployment will fail when using a custom docker image with kube-deploy , e.g REGISTRY=test TAG=031601f1 IMAGE_NAME=my-eg IMAGE_PULL_POLICY=IfNotPresent make kube-deploy

we discussed this in the communtiy meeting last week, adding a field in EnvoyGateway config and populating that via helm is probably the way to go here