228bc35e82
Here's what happens: 1. One runs `make binary` once 2. Days go by... 3. One makes changes to dockerd sources 4. One runs `make test-integration` to test the changes 5. One spends a long time figuring out why on Earth those changes in step 3 are ignored by step 4. 6. One writes this patch 7. ... 8. PROFIT!! OK, so `make test-integration` builds a dockerd binary in bundles/dynbinary-daemon/, when starts a daemon instance for testing. The problem is, the script that starts the daemon sets PATH to try `bundles/binary-daemon/` first, and `bundles/dynbinary-daemon/` second. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com> |
||
|---|---|---|
| .. | ||
| .resources-windows | ||
| .binary | ||
| .binary-setup | ||
| .detect-daemon-osarch | ||
| .ensure-emptyfs | ||
| .go-autogen | ||
| .go-autogen.ps1 | ||
| .integration-daemon-setup | ||
| .integration-daemon-start | ||
| .integration-daemon-stop | ||
| .integration-test-helpers | ||
| README.md | ||
| binary | ||
| binary-daemon | ||
| build-integration-test-binary | ||
| containerutility | ||
| cross | ||
| cross-platform-dependent | ||
| dynbinary | ||
| dynbinary-daemon | ||
| install-binary | ||
| run | ||
| test-docker-py | ||
| test-integration | ||
| test-integration-cli | ||
| test-integration-flaky | ||
| test-integration-shell | ||
README.md
This directory holds scripts called by make.sh in the parent directory.
Each script is named after the bundle it creates. They should not be called directly - instead, pass it as argument to make.sh, for example:
./hack/make.sh binary ubuntu
# Or to run all default bundles:
./hack/make.sh
To add a bundle:
- Create a shell-compatible file here
- Add it to $DEFAULT_BUNDLES in make.sh