This just makes it easier to build a targeted binary for the
goos/goach/goarm version.
This of course will not work for all cases but is nice to get things
going.
Specifically cross-compiling pkcs for yubikey support requires some
extra work whichis not tackled here.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 15130e3043)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This allows e.g.
$ make -f docker.Makefile fmt test-e2e-non-experimental TESTFLAGS="-test.run TestRunGoodArgument|TestRunGood"
As well as adding the var to `$(ENVVARS)` we also need to use that when
invocking the e2e image, the existing `$(DOCKER_RUN)` is not used here because
the bind mounts differ. The other variables included in `$(ENVVARS)` are
harmless when running the e2e tests.
The `${TESTFLAGS}` envvar is already understood by `scripts/test/e2e/run`.
Note that since this modifies `$(ENVVARS)` this is now also available to the unit
test target too, so add the use to the invocation so it takes effect.
Signed-off-by: Ian Campbell <ijc@docker.com>
Seems I rebased over b039db985a ("Make it possible to override the volume
mounts and shell for the dev container") at some point and failed to notice
that some of the variable names had changed.
In the meantime the underlying issue was fixed in #1698 but here we switch to
using `$(DOCKER_RUN)`. This means that these rules now use
`$(DOCKER_RUN_NAME_OPTION)` and thus obey the `$(DOCKER_CLI_CONTAINER_NAME)`
variable.
Signed-off-by: Ian Campbell <ijc@docker.com>
That is, the helper to be used from the plugin's `main`.
Also add a `helloworld` plugin example and build integration.
Signed-off-by: Ian Campbell <ijc@docker.com>
Through the `DOCKER_CLI_MOUNTS` and `DOCKER_CLI_SHELL` env variables. Also
allows setting the dev container name through the `DOCKER_CLI_CONTAINER_NAME`
env var.
The motivation for allowing overriding the volume mounts is the same as for
moby/moby#37845, namely that I/O perf on native mounted
disks on non-Linux (notably Mac OS) is just terrible, thus making it a real
pain to develop: one has to choose between re-building the image after every
single change (eg to run a test) or just work directly inside the same
container (eg with vim, but even then one would have to re-configure their dev
container every time it gets destroyed - containers, after all, are not
supposed to be long-lived).
Allowing to override DOCKER_CLI_MOUNTS makes it easy for everyone
to decide what their volume/syncing strategy is; for example
one can choose to use [docker-sync](https://github.com/EugenMayer/docker-sync).
As for the shell, it's nice to be able to use bash instead of the more
bare-bones `ash` if preferred.
Finally, being able to name the container can come in handy for easier
scripting on the host.
This patch won't change anything for anyone who doesn't set these env variables
in their environment.
Signed-off-by: Jean Rouge <rougej+github@gmail.com>
This patch adds support for multiple newlines and removes the 1-space
indentation of wrapped lines.
Given these targets:
```Makefile
.PHONY: foobar
foobar: ## runs the foobar lorum ipsum.\nand so pn\nand so on
echo foobar
```
Before this change, the output of `make help` was
```
foobar runs the foobar lorum ipsum.
and so pn\nand so on
```
After this change, the output is:
```
foobar runs the foobar lorum ipsum.
and so pn
and so on
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `make help` output was missing some targets (`fmt`, `test-unit`,
`test-e2e`).
Note that some targets are still hidden (`test-e2e-experimental`,
`test-e2e-non-experimental`, `test-e2e-connhelper-ssh`) as they're likely not
usually run separate from `test-e2e`.
Before this patch:
make -f docker.Makefile help
binary build the CLI
build alias for binary
clean clean build artifacts
cross build the CLI for macOS and Windows
binary-windows build the CLI for Windows
binary-osx build the CLI for macOS
dev start a build container in interactive mode for in-container development
shell alias for dev
lint run linters
vendor download dependencies (vendor/) listed in vendor.conf
dynbinary build the CLI dynamically linked
authors generate AUTHORS file from git history
manpages generate man pages from go source and markdown
yamldocs generate documentation YAML files consumed by docs repo
shellcheck run shellcheck validation
help print this help
With this patch applied:
make -f docker.Makefile help
binary build the CLI
build alias for binary
clean clean build artifacts
test-unit run unit tests (using go test)
cross build the CLI for macOS and Windows
binary-windows build the CLI for Windows
binary-osx build the CLI for macOS
dev start a build container in interactive mode for in-container development
shell alias for dev
lint run linters
fmt run gofmt
vendor download dependencies (vendor/) listed in vendor.conf
dynbinary build the CLI dynamically linked
authors generate AUTHORS file from git history
manpages generate man pages from go source and markdown
yamldocs generate documentation YAML files consumed by docs repo
shellcheck run shellcheck validation
test-e2e run all e2e tests
help print this help
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With a docker build cache already primed with the build image I am seeing
`time make build -f docker.Makefile DOCKER_BUILDKIT=1 GO_BUILD_CACHE=n` takes
more than 1 minute.
By contrast `time make build -f docker.Makefile DOCKER_BUILDKIT=1
GO_BUILD_CACHE=y` takes less than 10s with a hot cache irrespective of whether
the source tree has changed
Signed-off-by: Ian Campbell <ijc@docker.com>
When building the Dockerfiles for development, those images are mainly used to
create a reproducible build-environment. The source code is bind-mounted into
the image at runtime; there is no need to create an image with the actual
source code, and copying the source code into the image would lead to a new
image being created for each code-change (possibly leading up to many "dangling"
images for previous code-changes).
However, when building (and using) the development images in CI, bind-mounting
is not an option, because the daemon is running remotely.
To make this work, the circle-ci script patched the Dockerfiles when CI is run;
adding a `COPY` to the respective Dockerfiles.
Patching Dockerfiles is not really a "best practice" and, even though the source
code does not and up in the image, the source would still be _sent_ to the daemon
for each build (unless BuildKit is used).
This patch updates the makefiles, circle-ci script, and Dockerfiles;
- When building the Dockerfiles locally, pipe the Dockerfile through stdin.
Doing so, prevents the build-context from being sent to the daemon. This speeds
up the build, and doesn't fill up the Docker "temp" directory with content that's
not used
- Now that no content is sent, add the COPY instructions to the Dockerfiles, and
remove the code in the circle-ci script to "live patch" the Dockerfiles.
Before this patch is applied (with cache):
```
$ time make -f docker.Makefile build_shell_validate_image
docker build -t docker-cli-shell-validate -f ./dockerfiles/Dockerfile.shellcheck .
Sending build context to Docker daemon 41MB
Step 1/2 : FROM debian:stretch-slim
...
Successfully built 81e14e8ad856
Successfully tagged docker-cli-shell-validate:latest
2.75 real 0.45 user 0.56 sys
```
After this patch is applied (with cache)::
```
$ time make -f docker.Makefile build_shell_validate_image
cat ./dockerfiles/Dockerfile.shellcheck | docker build -t docker-cli-shell-validate -
Sending build context to Docker daemon 2.048kB
Step 1/2 : FROM debian:stretch-slim
...
Successfully built 81e14e8ad856
Successfully tagged docker-cli-shell-validate:latest
0.33 real 0.07 user 0.08 sys
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adapt the CLI to the host install model for 18.09.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit 342afe44fb)
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
This new collection of commands supports initializing a local
engine using containerd, updating that engine, and activating
the EE product
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
* Add the `help` target to document make targets when building using a
container
* Remove the `watch` target (filewatcher was removed with c0588a9c) from
docker.Makefile and Makefile
Signed-off-by: Marco Vedovati <mvedovati@suse.com>
- `make test-e2e` runs the e2e tests twice : once against on
non-experimental daemon (as before), once against an experimental
daemon.
- adds `test-e2e-experimental` and `test-e2e-non-experimental` target
to run tests for the specified cases
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
- Build image that contains everything needed to run e2e tests
- Add ability to run e2e tests against an endpoint
Signed-off-by: Christopher Crone <christopher.crone@docker.com>
The Server section of version output is now composed of an Engine
component and potentially more, based on what the /version endpoint
returns.
Signed-off-by: Tibor Vass <tibor@docker.com>
The test target existed before, this is to provide a legacy interface to
allow easy testing for downstream Docker CE.
Without this we would need separate Makefiles/Jenkinsfiles for releases
past 17.07. Later on this target could also be used to test both unit
tests and integration tests at the same time.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Fixes:
`make -f docker.Makefile binary`
When directories have characters like `&&` they must be wrapped in
quotes or else the docker run command will fail.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Remove referenced to developing on the host, we shouldn't support it.
Move script/validate to scripts/validate to be consistent.
Set the default target to be binary instead of clean.
Signed-off-by: Daniel Nephin <dnephin@docker.com>