feat(cli): support running a generator container with no network access - #17509
Draft
ATechAdventurer wants to merge 1 commit into
Draft
feat(cli): support running a generator container with no network access#17509ATechAdventurer wants to merge 1 commit into
ATechAdventurer wants to merge 1 commit into
Conversation
runDocker builds `docker run --user root [--pull always] [--platform ...] ...` with no --network flag at any point, so a generator always runs with default bridge networking. There is currently no way to generate offline. Adds an optional network mode threaded from ContainerExecutionEnvironment through runContainer, following the same shape as the existing platform and pull options. Set FERN_GENERATOR_NETWORK=none to run the generator with no network access. Unset, the flag is not passed and container networking is unchanged for every existing generator. An environment variable rather than a generators.yml key so the switch exists without a schema change; a first-class config field or CLI flag is the natural follow-up if that is preferred. Covered by tests asserting the assembled argv: the flag appears when requested, is absent by default, and is positioned ahead of the image and its arguments.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
runDockerassemblesdocker run --user root [--pull always] [--platform ...] -v ... -e ... image args. There is no--networkflag at any point, so a generator container always runs with default bridge networking, and there is currently no way to generate offline.This adds an optional network mode, threaded from
ContainerExecutionEnvironmentthroughrunContainer, following the same shape as the existingplatformandpulloptions.Unset, the flag is not passed and container networking is unchanged for every existing generator.
Why
Air-gapped and regulated environments need the generator to demonstrably have no network path. Today that isolation can only be enforced outside the CLI, which means the guarantee holds in a vendor's CI but not in the customer's actual run — the gap between "air-gap is provable" and "air-gap is what the customer gets".
Why an environment variable
It gives the capability without touching the
generators.ymlschema. A first-class config field or a CLI flag is the natural follow-up if that is preferred — happy to change it, this was the smallest surface that works.Testing
Three tests assert the assembled argv rather than mocking at a higher level:
--network <mode>appears when requestedAll 13 existing
docker-utilstests still pass, including thebasic-writerintegration test that runs a real container.I also confirmed against real Docker that the flag does what the PR claims: a
busyboxcontainer reaches the network by default and is blocked with--network nonein the position we emit it.Note
Draft while related work settles. Independent of #17508, though both touch
docker-utils.