The shorthand is more prevalent in this codebase, and is something that bash supports, so we should just use the same thing everywhere.
Note that we do not use shorthand redirect in Makefile as shell parsing is a bit different in Make and the shorthand redirect doesn't seem to be properly supported, causing CI errors.
While the majority of buildpacks do not work on non-amd64 platforms, this will at least allow developers the option to choose when to override this setting.
Herokuish is not and will never be supported on arm servers, so attempting to use it will only fail builds.
Also fail when trying to default to herokuish on armhf instances. We can't default to pack as it's just not built for armhf/arm (only arm64).
Closes#5113
This ensures the value is correct, where previously it was computed based on a file - and therefore did not distinguish between git:from-archive and git:from-image.
Closes#4464
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.
Git worktrees do not include the full .git directory - only a pointer to the actual directory - when keep-git-dir is set to true, which is incorrect for built containers. This change special-cases that combination, allowing folks on newer git installs to actually keep the .git directory during the build process.
Closes#4415
This fixes issues where alternative tools that don't trigger the init via sshcommand - such as git-http-backend - are not able to setup applications correctly.
Note that those apps could always manually trigger git:initialize if desired, but if the app already exists, then this should already _just work_ without that extra initialization.
This standardization makes it somewhat easier to read stacktraces as the command names are all uniform, so it will be slightly easier to scan trace output.
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 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.
While I do not agree with _every_ style change, this will force Dokku to have consistent formatting across all shell scripts, which is arguably a Good Thing™.
The command used to reprocess everything is:
```shell
shfmt -l -bn -ci -i 2 -w .
```
This is useful in contexts where the repository directory may be created and interacted with via git-http-backend or other methods of updating a repository.
- add `report` and `set` subcommands to the git plugin
- move configuring the DOKKU_DEPLOY_BRANCH to the git plugin
- implement configurable GIT_REV support
- migrate DOKKU_DEPLOY_BRANCH settings
- add a golang-compatible, shell based method of setting plugin configuration variables
Deprecates the community dokku-git-rev plugin.
Closes#2621
Refs dokku-community/dokku-git-rev#9
