Better would be to separate the release and deploy aspects into distinct triggers - as well as have it release a specific image - but this is a good first pass.
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.
A DOKKU_SCALE file will always be used for managing the scale count for an app if it exists in a repository. As such, ps:scale usage should be disabled in those cases. This commit makes that more apparent.
Also document how to build a specific core plugin for testing purposes.
Closes#3544
The previous output required too much parsing to be used in an automated fashion. This change makes that a bit easier, without sacrificing usability.
Note that the output is quite a bit different from heroku. This is purposeful as we do not have the concept of dynos.
Closes#3520
With the introduciton of procfile-util, scaling a non-existent process to 0 was disabled. This brings back that functionality, allowing users to scale all processes to 0. This is especially useful when a user has accidentally scaled a non-existent process up, causing deploys to fail without any way to revert outside of manually editing files.
Closes#3428
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 .
```
In some cases, a single allocation for a service may not be running, but the others will, and `is_app_running` will return the wrong thing.
Closes#2772
This will allow us to _actually_ introspect on the running state of an application. In certain cases, the detected state can be "mixed", meaning that we may need to take action, depending on what we want to do in mixed mode.
Applications without a restart-policy will have their policies set to `on-failure:10`. Users can completely unset the restart-policy using the `docker-options` plugin, though this will be equivalent to setting it explicitly to `no`.
Restart policies must be explicitly set, and the following are all valid:
- no
- unless-stopped
- always
- on-failure
- on-failure:NUMBER
