Change the way "inherited" workspaces retrieve the base workspace code

[jonnyry]

Problem

"Inherited" workspaces - airlock-import-review, unrestricted workspaces and our own custom workspaces - are built on top of the base workspace's code, to reduce duplication.

The base workspace code is pulled in in the inherited workspace's Dockerfile.tmpl file:

AzureTRE/templates/workspaces/airlock-import-review/Dockerfile.tmpl

Lines 16 to 19 in b69ab01

	# Copy all files from base workspace (note: some of them will be overwritten with the following COPY command)
	RUN curl -o azuretre.tar.gz -L "https://github.com/microsoft/AzureTRE/archive/refs/tags/v${AZURE_TRE_VERSION}.tar.gz" \
	&& tar -xzf azuretre.tar.gz "AzureTRE-${AZURE_TRE_VERSION}/templates/workspaces/base" --strip-components=4 --skip-old-files \
	&& rm -rf azuretre.tar.gz

The code is downloaded from a tagged version of the Azure TRE on GitHub, rather than by referencing the local copy of the base workspace, as the Docker build context does not allow access outside of the current working directory (the docker "build context").

This is unsatisfactory as every time the base workspace changes, for the change to be propagated to inherited workspaces, a versioned release of the Azure TRE is required, and then a subsequent commit is required to update this version number in inherited workspaces. Consequently inherited workspaces typically lag behind the base workspace by several versions as this step is often missed.

Proposed solution

Rather than pulling the base workspace code from a tagged release on GitHub, use the local base workspace code in the ../base workspace directory.

docker build now allows a --build-context parameter to be passed to containing additional named build contexts, which allows the referencing of files outside of the current build context.

https://github.com/docker/buildx/blob/master/docs/reference/buildx_build.md#-additional-build-contexts---build-context

This would then allow the COPY command to be used as follows:

COPY --from=my-build-context base/terraform/storage.tf .

In order for the above to be used a change to porter would be required to allow the passing of the --build-context parameter to the docker build command.

[marrobi]

@jonnyry completely agree, didn't realise could have multiple build contexts. When did this happen? As you say I think a PR to porter would be required to enable this.

[jonnyry]

Looks like it was sometime in 2022 with the release of Dockerfile 1.4:

https://www.docker.com/blog/dockerfiles-now-support-multiple-build-contexts/

I've opened a PR with Porter to support the --build-context parameter:

getporter/porter#3273

[jonnyry]

Addition to the solution so that --build-context is only called for bundles that need to use it, i.e. for the following workspaces:

airlock-import-review
unrestricted

In all other cases, the --build-context parameter is not used.

The bundle-build make target does this by looking for a file named porter-build-context.env in the workspace folder, if it exists, it grabs the additional build context from the file and passes it to porter build, else it runs porter build without the parameter.