The COMPANY_NAME currently sets the "CompanyName" field in the metadata
of Windows binaries. Our intent of this field is this field to contain
information about the company/party that produced the binary.
Also from [FileVersionInfo.CompanyName][FileVersionInfo.CompanyName]:
> Gets the name of the company that produced the file
Based on the above, "PACKAGER_NAME" is a bit more generic, and clearer
on intent, and we may at some point re-use this same information to
propagate equivalent fields on other platforms (rpms, debs)
[FileVersionInfo.CompanyName]: https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.fileversioninfo.companyname
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows us to drop the `//go:generate` and use of the github.com/mjibson/esc
utility.
worth noting that Go's native "embed" does not compress files. We could compress
these files as part of a build / validate step (which would add some complexity
when updating these files) if this is a concern, but not sure if the additional
complexity is warranted.
Comparing before/after sizes (see below);
macOS: 54125840 - 54005264 = 120576 (+120.58 kB)
Linux: 52393231 - 52277701 = 115530 (+115.53 kB)
Before:
ls -l build/
total 208736
lrwxr-xr-x 1 sebastiaan staff 19 Aug 15 09:36 docker@ -> docker-linux-amd64
-rwxr-xr-x 1 sebastiaan staff 54005264 Aug 15 09:35 docker-darwin-amd64*
-rwxr-xr-x 1 sebastiaan staff 52277701 Aug 15 09:36 docker-linux-amd64*
After:
ls -l build/
total 208960
lrwxr-xr-x 1 sebastiaan staff 18 Aug 15 09:32 docker@ -> docker-linux-amd64
-rwxr-xr-x 1 sebastiaan staff 54125840 Aug 15 09:31 docker-darwin-amd64*
-rwxr-xr-x 1 sebastiaan staff 52393231 Aug 15 09:32 docker-linux-amd64*
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 01cd748eb6 started using
Dockerfile features that are currently only supported with
buildkit enabled.
While we enabled buildkit in our Jenkinsfile, the makefile
did not do the same, causing some targets to fail if buildkit
was not enabled.
This patch updates the makefile to enable buildkit.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The shorthand `-v` will auto-create the host-path as a directory if
the socket is not yet up, instead of failing the container. To prevent
accidental creation of `/var/run/docker.sock` as a directory, use
the `--mount` flag instead, which does not auto-create host-paths.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Bash is installed already, so we might as well use it as a default.
This also removes the DOCKER_CLI_SHELL variable, which was added
in b039db985a to allow using bash
instead of (a)sh. Now that Bash is the default, there should be
no need to override, and we can keep things simple.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is currently just a copy of the v3.8 schema, in preparation
of new features to be added in the new schema.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows overriding the version of Go without making modifications in the
source code, which can be useful to test against multiple versions.
For example:
make GO_VERSION=1.13beta1 -f docker.Makefile binary
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
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>
Sebastiaan van Stijn
CrazyMax
Tonis Tiigi
Silvin Lubecki
Brian Goff
Ian Campbell
Jean Rouge
Sebastiaan van Stijn
Akihiro Suda
Daniel Hiltgen
Marco Vedovati
Vincent Demeester
Christopher Crone
Daniel Nephin
Tibor Vass
Eli Uriegas
Vincent Demeester
Lei Jitang