bug(render/v2.3.0): function docker network is overwritten and crossplane container always start in temporary network

[nkzk]

What happened?

Since v2.3.0, crossplane render uses crossplane's engine to render the compositions. By default this is done by starting up crossplane as its own container in a temporary network, and overwriting the docker-network annotation on all functions to join it.

This new default behavior has two problems we have encountered:

1. This doesnt support starting/stopping functions yourself so that you can run multiple renders without starting/stopping the functions on each run.
   Since the temporary crossplane-render network and crossplane-container is created on each render-run you'd need to connect the containers to this new network, for every render.

2. Running crossplane render in a devcontainer / docker-in-docker / podman-in-podman
   If you run crossplane-render inside a container, you need to ensure that containers started by crossplane-render run in the same network as the container you are in (or in a connected network).
   Previously you could control this with the docker-network annotation, either with -a or as annotation in the functions-file, but since the crossplane-container always starts up in a temporary network, there's no connectivity to the crossplane-container. If function-containers already run, i'm unsure if the annotation overwriting has any effect.
   Circumventing this would require a bit of hacking.

How can we reproduce it?

Run crossplane-render in ci (DinD) or devcontainer.

What environment did it happen in?

• Crossplane CLI version: v2.3.1
• Platform (e.g., linux/amd64): linux/amd64

[nkzk]

I have started on a pull request to fix this in #65, just have to fix tests and make the PR reviewable.

I propose the following fixes:

• Do not overwrite the docker-network annotation in functions if it has already been set
• If the docker-network annotation is passed to the FunctionAnnotations flag, run crossplane-container in it.

You could probably argue that the user can pass the CrossplaneBinary flag so that it runs as before, but since this is the default behavior i think a fix like this makes sense? Also the user would need to download the crossplane binary in addition to the cli..

[jcogilvie]

Filed #96 for an adjacent multi-composition-in-one-process problem on the same Engine.Setup code surface — flagging it here in case the maintainers want to consolidate review or pick a fix shape that covers both.

Quick map:

Problem	Issue	Symptom
Cross-invocation function-container reuse	this issue (problem 1)	Containers stranded on prior network; can't reach them on next run
DinD / devcontainer network override	this issue (problem 2)	Render container unreachable from caller container; addressed by #65
Intra-process multi-composition	#96	New functions discovered mid-process land on default bridge instead of the engine's network

#96 proposes either an idempotent Engine.Setup or a new Engine.AnnotateFunctions method. The idempotent-Setup option would also close this issue's problem 1 — a caller could re-Setup with the same engine to add functions to its network across runs, and a stable-named network would naturally fall out of that.