The previous tar support lacked the ability to track changes between tarball deploys. Critically, it also failed to be handled correctly when there was _also_ a git deployment done on the app, resulting in odd deployment states depending on the angles of the moon and the sun in the sky.
Rather than try to "fix" this through some hokey mechanism, importing the tar file contents into the git repository is preferred, as then the user can refer to the repository for commit history.
Additionally, we add support for non-tar files (tar.gz and zip), enabling deployments from systems that do not create tar files, such as Github (their tarball url is a tar.gz file).
Finally, this deprecates the tar plugin, and sets it to be removed in the next minor release (in addition to the tags plugin).
Closes#3458Closes#4207
The new command superscedes the previous tags plugin, and integrates docker image deployment with the general build process.
While `docker image load` is not supported, this otherwise completely handles all previous workflows supported by the `tags:deploy` command, while doing so in a much easier to use interface.
Closes#4296
Rather than hardcode two builders, allow builders to specify a `builder-detect` trigger. This trigger can be used to specify if the builder should or should not be used for an application. Each builder takes stdin and can decide if it wants to emit it or emit it's own image source type.
If the final value is empty, then Dokku will default to herokuish (and cnb once that is stable). In addition, a future change may allow users to manually specify a builder in the case they wish to override the choice selected by Dokku.
This change enables users to build custom builder plugins and have those plugins used for building an image asset. By way of example, an enterprising user could create a `builder-lambda` based on lambci, and then pair this with a scheduler plugin that updates a lambda function on AWS. Alternatively, a user might decide they wish to place their Dockerfile in a specific directory for their applications - such as an `_infrastructure` directory - and create a plugin to override how that is detected within Dokku.
This occurs during the postdeploy on the first deploy of an app, mimicking heroku. It currently happens _after_ the `postdeploy` and `release` deploy tasks.
# History
## 0.23.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.9/bootstrap.sh
sudo DOKKU_TAG=v0.23.9 bash bootstrap.sh
```
### Refactors
- #4445: @josegonzalez Bump azure template and formula directly on release
### Documentation
- #4444: @josegonzalez Uuse updated links for documentation
- #4439: @RyukerLiu View Doc redirect not working. Change to use direct link
Rather than try and do something fancy on tag creation via workflows - which won't trigger due to workflows not being able to trigger other workflows without using workflow_run on the downstream workflow as a trigger - we just do all the releasing at once. This makes it easy to understand whether a release fully completed.
# History
## 0.23.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.23.8/bootstrap.sh
sudo DOKKU_TAG=v0.23.8 bash bootstrap.sh
```
### Bug Fixes
- #4437: @josegonzalez Switch to using GIT_DIR environment variable to fix Centos 7 support
- #4436: @josegonzalez Properly handle directory change when cleaning .git directory
### New Features
- #4428: @josegonzalez Bump azure ARM quickstart template on release
### Documentation
- #4435: @josegonzalez Change page title based on current page
- #4427: @josegonzalez Change process management doc references to make more sense
### Other
- #4438: @josegonzalez Split out nginx tests further to decrease overall CI runtime
- #4430: @dependabot-preview[bot] chore(deps): bump jetty-servlet from 11.0.0 to 11.0.1 in /tests/apps/java
