Hi team, I noticed that flyte 1.10.0 and 1.10.1 he...
# ask-the-community
g
Hi team, I noticed that flyte 1.10.0 and 1.10.1 helm charts still refer to the docker version of 1.9.37 of it’s components. Does this mean noone built the docker images for the flyte components for 1.10.x ? Also is 1.10.x version the same as 1.9.37 and can we use it instead ?
y
yes
you can see from this job https://github.com/flyteorg/flyte/actions/runs/6592273299/job/17913579401 that these two tags are the same
Copy code
<http://ghcr.io/flyteorg/flyteadmin:v1.9.37|ghcr.io/flyteorg/flyteadmin:v1.9.37>
and
<http://ghcr.io/flyteorg/flyteadmin:6f02b4c164f0f229628d02ef2e63fbe273847fd6|ghcr.io/flyteorg/flyteadmin:6f02b4c164f0f229628d02ef2e63fbe273847fd6>
the 6f commit is the commit prior
i think we might play around with tagging a bit more. there’s a bit of a chicken and egg problem not that everything’s in the same repo. (ie the commit that updates the values can’t be same commit as the release itself) but that’s not necessarily true if we don’t reference actual git shas anywhere (i don’t know if we do)
g
ok, I raised this cause it seemed to me a bit strange that a 1.10 release references 1.9.x artefacts that’s all. Maybe before a new major release, there should be a pre-release commit to tag the docker images and then the final release commit that updates the references in the chart.
moreover flyteconsole is tagged with 1.10.x release tag
y
@Eduardo Apolinario (eapolinario) whenever you get a chance…
e
Yeah, we're aware of that. As @Yee pointed out, we're still playing around with this, but if you take a look at the official helm charts, they all use the correct tag, e.g. https://artifacthub.io/packages/helm/flyte/flyte-core.
This discrepancy is annoying and we'll fix it, but from the perspective of consumers of the official helm charts the version is correct.