[Templates][Devcontainers] docker build cache would prevent installing latest azd version on containers.

[vhvb1989]

We use

RUN curl -fsSL https://aka.ms/install-azd.sh | bash

as the last step of the dockerfile for the .devcontainer settings. This build step is automatically cache by docker and won't be built if there are no changes on previous layers.

From docker:

Suppose you have a RUN apt-get update && apt-get upgrade -y step in your Dockerfile to upgrade all the software packages in your Debian-based image to the latest version.

This doesn’t mean that the images you build are always up to date. Rebuilding the image on the same host one week later will still get you the same packages as before. The only way to force a rebuild is by making sure that a layer before it has changed, or by clearing the build cache using [docker builder prune](https://docs.docker.com/engine/reference/commandline/builder_prune/).

https://docs.docker.com/build/cache/

Because of this, as a user, I can get previous azd version which is part of docker cache. I need to run docker builder prune to make sure I am getting the latest, but the build time will also be impacted, as I will be re-building all layers as the very first time.

What about moving azd install to devcontainer.json instead?

[jongio]

@bamurtaugh - Do you think the right approach here is to put in devcontainer.json as a post* command?

[bamurtaugh]

@jongio I think that's a good idea.

Or what about creating a dev container Feature, which you could also choose to contribute back to the dev container spec index so any user can easily grab the azd functionality? As I'm exploring the dev containers in this repo, I'm seeing the use of other Features (which is awesome!), so I'm wondering if it makes sense to also create one for azd directly, for both this repo and beyond.

cc @samruddhikhandale for any other thoughts.

[jongio]

Thanks - @rajeshkamal5050 - Maybe we prioritize this? #1095

[samruddhikhandale]

Creating a dev container Feature for this is wonderful and would be helpful for the community. However, the Features are cached as well and I am worried it would be the same caching issue all over again.

I think installing azd should be part of a lifecycle command (say "postStartCommand", so we can ensure that every time the container is started, the latest version is installed)

Features now support adding lifecycle hooks, so probably worth creating a new azd Feature and ensuring that there's a Feature option which adds azd installation to the lifecycle command?

@bamurtaugh feel free to correct me if I have misunderstood anything here! :)

[rajeshkamal5050]

@vhvb1989 is this issue still valid with @hemarina adding GHA and DevContainer feature for Azd?

I believe GHA and DevContainer will be version controlled. So users have a deterministic behavior in pipelines. Instead of latest versions of Azd flowing through causing issues.

cc: @savannahostrowski @ellismg

[vhvb1989]

@rajeshkamal5050 , as per @samruddhikhandale, DevContainers are also cache. The suggestion was to use a docker-hook to install azd.

The GHA is specific for running CI/CD. This issue affects the local dev environment primarily, when using a dev-container from a template which automatically installs azd.

[rajeshkamal5050]

DevContainers are also cache

Pinned version(Azd DevContainer feature) + caching gives a deterministic run of pipelines instead of pulling latest Azd bits. If I remember correctly, @danieljurek?? CSS was also asking for a mechanism for pinning Azd in pipelines. So that even when we release Azd bits, customers are not surprised with latest bits being pulled in pipelines causing breakages.

Let us not recommend for pulling latest and greatest Azd bits in the pipelines. Instead, lets recommend using pinned versions of Azd in pipelines.