Azure-docs: Trigger by commits

[robertdj]

This is great stuff. But I have a problem builds triggered by commits.

I have the Dockerfiles for both the base image and the application image in the same repository. When I start the base image build manually it triggers the application build upon completion.

When I push to the repository both builds start at the same time. The base image build succeeds and the application image build fails because it needs the new base image (this is specific for my setup).

However, I imagined that when the base image build finished it would trigger a new build of the application image, but this is not the case. Have I overlooked something?

Edit: I think I have found the issue. The dependency is on image and tag. My tag is set with a values.yaml in the repository file. My hope was that this dependency on values.yaml would be detected. But it appears to be the value used at the time of task creation that is used in the dependency.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b4afe907-4a5f-1f3e-b044-6f96068b3c1f
• Version Independent ID: 718454ef-3a3e-c256-44cc-3778cefca397
• Content: Tutorial - Automate container image builds on base image update - Azure Container Registry Tasks
• Content Source: articles/container-registry/container-registry-tutorial-base-image-update.md
• Service: container-registry
• GitHub Login: @dlepow
• Microsoft Alias: danlep

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[mimckitt]

@dlepow @iainfoulds would either of you have anything to comment on this?

[dlepow]

@robertdj - Thanks for posting your question and explaining your scenario. Could you tell us a little more about how you are running your task? For example, are you creating and running a single task as described in that article, or are you using a multi-step task defined in a YAML file? Your scenario with dependent tasks sounds like a good application of the multi-step task, and for passing in the tag value you might want to look at this sample.

Let us know if this helps, or feel free to provide command examples from your environment (stripped of any identifying info of course) so we can investigate further. Thanks!

[robertdj]

@dlepow : Certainly! This is related to a question I had previously: https://github.com/MicrosoftDocs/azure-docs/issues/27183

I use a multi-step task in a YAML file. I suppose I'm looking for a parametrized series of dependent builds.

In the tutorial setup the Dockerfile-base has ENV NODE_VERSION 9.11.2. I want to set NODE_VERSION as a build argument that is read from a values.yaml. Something like having a values.yaml with the entry nodeversion: 9.11.2 and then a docker build (in a YAML file) like

docker build --build-arg {{.Run.Registry}} --build-arg {{.Values.nodeversion}} -t {{.Values.nodeversion}} .

The Dockerfile-app would then start with

ARG REGISTRY
ARG NODE_VERSION
FROM ${REGISTRY}/baseimage:${NODE_VERSION}

The Docker image with app would also have the tag {{.Values.nodeversion}}.

Now this all works, but is tied to the value of {{.Values.nodeversion}} when the task is created. It would be cool if every new value of {{.Values.nodeversion}} would create a new base/application dependency -- without having to run the two tasks manually the first time.

[dlepow]

@robertdj - Thanks for the details. I'll defer to the product experts.
@sajayantony @northtyphoon - Do you have any suggestions about this scenario with ACR Tasks? Thanks!

[SteveLasker]

Hi @robertdj
It sounds like you're tripping up on two Tasks getting triggered on the same git repo. We talked about git trigger filters, but another approach is to keep the base image in another repo. The theory being you have lots of apps that likely depend on the base image.
You can see an example here: https://github.com/demo42
The web front end (https://github.com/demo42/web) depends on the node base image: https://github.com/demo42/baseimage-node
When the code in the web app changes, it triggers the task to build/deploy the web image
When the baseimage-node image gets rebuilt, all dependent images are rebuilt- such as the web app.
Here's a session on the demo: https://channel9.msdn.com/Events/Build/2018/BRK3812

The ${NODE_VERSION} version is another interesting example. I played with this a bit, but found too many abstractions made it hard to troubleshoot. I was trying to balance the stable and unique tags I blogged here: https://stevelasker.blog/2018/03/01/docker-tagging-best-practices-for-tagging-and-versioning-docker-images/
Please let us know if this helps, and we can add some more detailed docs as we understand which part we should enhance.
BTW, it would be great to talk with you about your specifics. Please feel free to reach out @ steve dot lasker @ microsoft

[robertdj]

Thank you for the responses.

@SteveLasker : I've sent you an email with more specific details.

[robertdj]

It turns out that my problem is actually fixed by using a suitable multi-step task where I define the dependency between the images.