e9ecd5e486
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>
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| .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 | ||
| binary | ||
| binary-daemon | ||
| build-integration-test-binary | ||
| containerutility | ||
| cross | ||
| cross-platform-dependent | ||
| dynbinary | ||
| dynbinary-daemon | ||
| install-binary | ||
| README.md | ||
| run | ||
| test-docker-py | ||
| test-integration | ||
| test-integration-cli | ||
| test-integration-shell | ||
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