You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 11, 2025. It is now read-only.
Here we've told `dockersource` to use `contrib/mod.sh` as a tool to handle replacements.
71
+
Here we've told `gnarly` to use `contrib/mod.sh` as a tool to handle replacements.
72
72
The `contrib/mod.sh` script uses `contrib/lookup.json` as a lookup table for replacements.
73
-
For each ref that is found in the Dockerfile by `dockersource`, the `contrib/mod.sh` is called with the found ref as the first argument. The `contrib/mod.sh` script can return an empty string or a replacement ref.
73
+
For each ref that is found in the Dockerfile by `gnarly`, the `contrib/mod.sh` is called with the found ref as the first argument. The `contrib/mod.sh` script can return an empty string or a replacement ref.
74
74
You can specify a path to a config file to use, which will be passed along to the mod-prog as an environment variable `MOD_CONFIG`.
75
75
76
76
The output of this is saved to `Dockerfile.mod` which is a special file that the syntax parser shown above will parse to handle replacements.
@@ -94,7 +94,7 @@ In some cases you may not want to modify the main build context with a Dockerfil
94
94
95
95
```console
96
96
$ dir="$(mktemp -d)"# Make a temp dir where we'll store the Dockerfile.mod
97
-
$ ./dockersource --format=modfile --mod-prog=contrib/mod.sh --mod-config=contrib/lookup.json | tee "${dir}/Dockerfile.mod"# Generate the Dockerfile.mod and store it in the temp dir created above.
97
+
$ ./gnarly --format=modfile --mod-prog=contrib/mod.sh --mod-config=contrib/lookup.json | tee "${dir}/Dockerfile.mod"# Generate the Dockerfile.mod and store it in the temp dir created above.
@@ -152,13 +152,13 @@ If so it will auto-generate the replacements and inject the neccessary arguments
152
152
153
153
This can be done in one of two ways:
154
154
155
-
1. You can create a symlink (or just call the binary `docker`...) to the `dockersource` binary called `docker`. Any invocation where against this symlink will make it act as a docker wrapper., e.g. `ln -s ln -s ./dockersource docker`
155
+
1. You can create a symlink (or just call the binary `docker`...) to the `gnarly` binary called `docker`. Any invocation where against this symlink will make it act as a docker wrapper., e.g. `ln -s ln -s ./gnarly docker`
156
156
2. In lieu of symlinking or other such methods, you can set the environment variable `DOCKERFILE_MOD_INVOKE_DOCKER=1`, this has the same affect as 1.
157
157
158
158
This can completely wrap docker (even `docker run`, `docker exec`, etc).
159
159
This should work with 100% of use cases **except** since it is are trying to generate mod data for builds, remote build contexts (e.g. `docker buildx build <URL>`) are not currently supported.
160
160
The workaround for this is to pre-generate your mod files and pass the path as an environment variable `DOCKERFILE_MOD_PATH=<path to Dockerfile.mod>`.
161
-
This workaround is going to be the best way to make sure no builds fail because of some missing functionality in `dockersource`.
161
+
This workaround is going to be the best way to make sure no builds fail because of some missing functionality in `gnarly`.
162
162
163
163
This will also inject `buildx` into a build invocation if `docker build` does not support the `--build-context` flag.
164
164
Example: `docker build .` will be changed to `docker buildx build .`.
0 commit comments