the proxy sha inside istio.VERSION should be working though
what in the build changes it ? (the build should only change the mixer/pilot/... shas/tags)

https://k8s-gubernator.appspot.com/build/istio-prow/pull/istio_istio/3616/istio-presubmit/5271/

Search for PROXY_TAG. You will find that early on it is 4ba2.
By the time you see integration.sh being run, istio.VERSION has been updated to shas that are not in the mainline any more.

istio.deps does not get updated by build, so it is more stable.

/lgtm
accepting this because everything is broken but there must be something else wrong if the proxy sha gets overwritten in istio.VERSION - it might get wrong for release yaml too - cc @mattdelco

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ldemailly

The full list of commands accepted by this bot can be found here.

/test all [submit-queue is verifying that this PR is safe to merge]

It seems very fragile to just use tail to grab the last instance of lastStableSHA in istio.deps and assume it's for proxy. Perhaps better option is to grab the SHA from pilot/docker/Dockerfile.proxy .

As best I can tell, people have two very different ideas about what PROXY_HUB / PROXY_TAG refer to. The proxy repo creates (via script/release-docker) docker images called "envoy" and "envoy-debug", which is apparently what this change/test wants to refer to. The istio repo creates other images called "proxy", "proxy_debug", and "proxy_init", which is probably what PR #2303 had in mind when it expanded the -a parameter of install/updateVersion.sh to also start setting the PROXY_HUB/PROXY_TAG (rather than just the options for pilot, mixer, and ca).

The updateVersion.sh script gets run in this test script as a side-effect of the "make push". A release build instead runs updateVersion.sh as part of "make istio-archive", though for this target it uses a long list of parameters instead of -a (so PROXY_HUB/PROXY_TAG isn't overridden) but even if it did override proxy this test wouldn't see it since the script it told to output to ${ISTIO_OUT} rather than scribble in the source tree.

If PROXY_HUB/PROXY_TAG is supposed to refer to istio's proxy/proxy_debug then this change was headed down an okay direction but should probably consult something else like Dockerfile.proxy . A potential complicating factor to consider is this potential change (or another TBD implementation) for people who want to build more of istio from local source:

master...mattdelco:master16

If PROXY_HUB/PROXY_TAG is intended to refer to proxy's envoy/envoy-debug then there's probably more things to straighten out (not the least of which is the behavior of the -a parameter in updateVersion.sh).

what's the plan fwd ? do we know why the build was changing the proxy tag ?

The folks I casually surveyed seemed to think that PROXY_HUB/PROXY_TAG is for proxy/proxy_debug in the istio repro ("pilot's proxy", as some said). This is consistent with how "make push" builds the majority of the docker images in the istio repo and runs "updateVersion.sh -a" to update the various xxx_HUB / xxx_TAG settings (including the ones for proxy) to point to what was built by "make push". The tag should correspond with the result of the current $(git rev-parse --verify HEAD) in the istio repo.

The main source of truth for the artifacts to use from the proxy repo is in the pilot/docker/Dockerfile.proxy[_debug], as that's what used by bin/init.sh and to build "pilot's proxy".

I think the correct way is to still use istio.deps but use jq to query the sha from the correct place.
I was not sure last night if jq is present on the build machines.

The purpose of istio.deps is to keep depedencies in machine readable format.
I would argue that the build scripts for docker should use this information as the source of truth.