If I understand correctly, this will be a breaking change with the declarative pipeline but a bug fix for the autodiscovery plugin.
I am not sure anymore, but I think we were using the hasPRefix because at that time, Updatecli couldn't handle stage information such as.

FROM golang as build

Which we do now.

TBH, I don't understand how this change would introduce a breaking change for the autodiscovery plugin, normally it should handle every image independently. In fact, using string comparison over checking prefix is even a bug fix for the autodiscovery because a multi-stage Dockerfile containing both python and python_runtime wouldn't be idempotent as Updatecli could use the python tag to update the python_runtime depending on the order of the generated manifests.

To play extra safe, we could use regex over string comparison, but then we would always need to specify $xxx^ which imho bring a bad UI

So my take on this would be to consider this as a bug and use string comparison

To me

Then we need to revisit the autodiscovery, at the moment to get all image in a dockerfile we check for all FROM instruction matching "" as the matching is with Prefix, it gives us all the docker images in the dockerfile.

The way I expect this to work is:

• FROM matching should be exact match
• autodiscovery should find all docker images in a dockerfile that are not a stage name:

FROM golang AS golang_builder
FROM scracth
FROM golang_builder
FROM python

Should find ["golang", "scratch", "python"] to update and only update thoses

Sorry for the stupid question, but why do you want to ignore stage images? I don't understand
Right now, we detect all of them. I just did a quick check and the pipelines are executed in the order of appearance which is a good think there is still the problem to update the wrong docker image tag

The behaviour I see is

FROM python:3.14 AS python-runtime

RUN apk add git

FROM python-runtime AS builder
...
FROM python-runtime AS dev
...

So we have base runtime, that we call python-runtime, it's reused multiple time.

When i run autodiscovery, I expect to only update the first one, the others are not docker images per se

Haaa good point thanks for the clarification

Re-triggering the unit tests, for some reason it's failing, but I don't seem to be able to reproduce locally :/

I could reproduce executing multiple time go test -count=1

And the dockerfile e2e tests are not passing for the autodiscovery

The e2e tests are not passing because they rely on docker images hosted on DockerHub, but pull request don't have access to DockerHub credentials for obvious security reason. I'll try to find some time to make the tests passing

So for some reason, the changes introduce in this pull request would detect this Dockerfile with an image not available on DockerHub 🤷🏾