Mascali/netbox-docker
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Refactor to multistage builds

Browse source 
This commit introduces a huge change in the build process.

What changed:

- Dockerfile.ldap was integrated into Dockerfile as a seperate
  [build stage][multistage-build].
- All the build scripts were refactored according to this.
- The `docker-compose.yml` file was adjusted likewise.
- The main build script, `/build.sh`, now always builds all
  targets (formerly called variants).
- The minimal requirements for Docker and docker-compose
  have increased.
- The build on hub.docker.com must be adjusted.

This change should also fix #156 permanently.

[multistage-build]: https://docs.docker.com/develop/develop-images/multistage-build/
This commit is contained in:
Christian Mäder 2019-10-10 12:42:10 +02:00 • committed by Christian Mäder
parent c148d3ceb9
commit d0ebb34432
11 changed files with 259 additions and 246 deletions
Download patch file Download diff file Expand all files Collapse all files

31
DOCKER_HUB.md
View file

@ -12,28 +12,16 @@ Repository Links: Enable for Base Image
Build Rules:
- Source Type: Branch
Source: master
Docker Tag: branches-main
Docker Tag: branches
Dockerfile location: Dockerfile
- Source Type: Branch
Source: master
Docker Tag: branches-ldap
Dockerfile location: Dockerfile.ldap
- Source Type: Branch
Source: master
Docker Tag: prerelease-main
Docker Tag: prerelease
Dockerfile location: Dockerfile
- Source Type: Branch
Source: master
Docker Tag: prerelease-ldap
Dockerfile location: Dockerfile.ldap
- Source Type: Branch
Source: master
Docker Tag: release-main
Docker Tag: release
Dockerfile location: Dockerfile
- Source Type: Branch
Source: master
Docker Tag: release-ldap
Dockerfile location: Dockerfile.ldap
Build Environment Variables:
# Create an app on Github and use it's OATH credentials here
- Key: GITHUB_OAUTH_CLIENT_ID
@ -51,16 +39,15 @@ The build system of cloud.docker.com is not made for this kind of project.
But we found a way to make it work, and this is how:
1. The docker hub build system [allows to overwrite the scripts that get executed
for `build`, `test` and `push`](overwrite). See `hooks/*`.
2. Shared functionality of the scripts `build`, `test` and `push` is extracted to `hooks/common`.
3. The `build` script runs `run_build()` from `hooks/common`.
This triggers either `build-branches.sh`, `build-latest.sh` or directly `build.sh`.
for `build`, `test` and `push`](overwrite). See `/hooks/*`.
2. Shared functionality of the scripts `build`, `test` and `push` is extracted to `/hooks/common`.
3. The `build` script runs `run_build()` from `/hooks/common`.
This triggers either `/build-branches.sh`, `/build-latest.sh` or directly `/build.sh`.
4. The `test` script just invokes `docker-compose` commands.
5. The `push` script runs `run_build()` from `hooks/common` with a `--push-only` flag.
This causes the `build.sh` script to not re-build the Docker image, but just the just built image.
The _Docker Tag_ configuration setting is misused to select the type (_release_, _prerelease_, _branches_) of the build as well as the variant (_main_, _ldap_).
The _Dockerfile location_ configuration setting is completely ignored by the build scripts.
The _Docker Tag_ configuration setting (`$DOCKER_TAG`) is only used to select the type (_release_, _prerelease_, _branches_) of the build in `hooks/common`.
Because it has a different meaning in all the other build scripts, it is `unset` after it has served it's purpose.
[overwrite]: https://docs.docker.com/docker-hub/builds/advanced/#override-build-test-or-push-commands