It may be desirable to keep the contents of the git directory for the build process. Certain build tools can extract extra information from the .git directory, and some workflows may require that the shipped artifact has the entire source code available locally for later usage.
This change refactors the compiled golang plugins into 3 distinct binaries:
- commands: already existing
- subcommands/subcommands: entrypoint into all subcommands
- triggers: entrypoint into all triggers
It then further symlinks triggers and subcommands to the built binaries. This results in both a much faster build process as well as smaller package size.
This PR uses the new syntax for commands introduced in Docker 1.13, making it a bit easier to understand just what a particular command is trying to do.
This also pushes the long-form syntax for docker command flags, which are also easier to understand at a glance.
This will allow background processes to cleanup these files if they were unable to be cleaned up during a run of the dokku binary, as is the case for files copied by the docker binary when running in docker.
This will allow those triggers to insert and extract files from the sourcecode work directory. Note that changes are not committed to this directory, nor will they be reflected in the committed codebase.
# History
## 0.18.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.18.1/bootstrap.sh
sudo DOKKU_TAG=v0.18.1 bash bootstrap.sh
```
### New Features
- #3636: @josegonzalez Unify deb and rpm creation code
- #3635: @josegonzalez Upgrade herokuish to 0.5.2
# History
## 0.18.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.18.0/bootstrap.sh
sudo DOKKU_TAG=v0.18.0 bash bootstrap.sh
```
### Bug Fixes
- #3627: @josegonzalez Make image removal synchronous
- #3618: @josegonzalez Ensure the dokku-retire timer is properly installed
- #3614: @alexquick Validate args for config:set and config:unset
- #3605: @josegonzalez Handle case where there are empty newlines in the authorized_keys file
- #3603: @josegonzalez Drop extra % sign in common.LogVerboseQuiet
- #3597: @josegonzalez Allow default trace function to work
### New Features
- #3628: @josegonzalez Handle file copying in a secure and reliable fashion
- #3630: @josegonzalez Fix issue where push warning on bad branch was skipped
- #3629: @josegonzalez Avoid calling the user-auth trigger where possible
- #3626: @josegonzalez Builder plugins
- #3599: @josegonzalez Scope docker-cleanup to specific app
- #3589: @michaelshobbs Allow running Dokku in Docker
- #3607: @josegonzalez Purge cache using herokuish image
- #3602: @alexymik Create a 502 error page to automatically refresh if backend status changes
- #3600: @josegonzalez Refactor IsImageHerokuishBased to match shell version
### Documentation
- #3625: @josegonzalez Remove old reference to SPONSORS.md
- #3619: @josegonzalez Cleanup plugin creation docs
- #3612: @jayjun Improve testing docs
- #3613: @Lyelt Remove all uses of proxy_set_header Connection "upgrade"
- #3596: @josegonzalez Add missing hooks to events plugin and plugin triggers docs
### Tests
- #3610: @jayjun Correct Bats path in single tests
If you are running docker in docker, the permissions on the generated file are such that they may not be accessible by the normal dokku user. For dokku, it is good enough to ignore the failed removal.
If "docker cp" is run within docker, it seems the owner is root, resulting in other processes not being able to directly read the file without resorting to `cat` trickery. Doing this in a single place avoids the problem completely.
Asynchronous image removal would remove intermediate build images during the build process, causing intermittent build failures for users of multi-stage dockerfiles. While we still remove intermediate docker images that may be used in the current build, we now do so during the deploy, ensuring that there are no intermediate build failures in the future.
Closes#3474
As this trigger is always in the execution path, `plugn` starts and expensively checks to see if it can execute the trigger. Rather than call this on every invocation, skip the trigger if no non-core implementation exists.
This is a "one-shot" ability, meaning that it is highly discouraged for multiple plugins to implement the triggers.
The `builder-create-dokku-image` trigger is meant to modify the base DOKKU_IMAGE that will be used to build an application. A good use of the hook is to inject system packages by:
- calculating an image tag from the set of system packages
- checking that the image doesnt already exist
- creating the image if it does not
As the output is sent to stdout, we have to find an alternative way of fetching the new DOKKU_IMAGE. The `builder-dokku-image` trigger can output an image tag based on the calculated image tag. If no tag is output, then the DOKKU_IMAGE is used as is.
Using this pattern, users can efficiently modify the base image in use for an app without duplicating the work on every push. This is especially useful for package installation, where packages are required for app building, but may take a long time and can be error prone.
A builder plugin implements some method for 'building' artifacts from a given source code archive. This refactor moves the majority of the image building code into separate plugins, allowing us to implement other builders, but also simplifying the common pugin codebase.
Also move the pre-build-buildpack hook from the build-env plugin to builder-herokuish.
