Heroku's ruby project changed its default branch from master to main.
This broke the examples in the documentation. This change explicitly
names main and master.
Previous versions extracted the values as strings, prefixing the values with `/bin/sh -c '$CMD'` unnecessarily. This caused issues where we would incorrectly overrride these values when an app had a predeploy script.
Closes#3143
These are usually not optional and actually explain what a user is interested in. As we don't have documentation partials, duplication isn't in favor of the project maintainer's benefit.
Closes#3927
While the latest packages may continue to work on other releases, we will no longer officially support these releases, nor will we distribute packages.
This change removes all deprecated commands. In many cases, users have been warned for a number of releases before the commands have been removed. All commands that were removed have existing alternatives.
The deployment documentation on scoping user access pointed only to the
development documentation for implementing plugins to handle user
scoping.
Added link to the dokku-acl plugin, which already handles user scoping
out of the box.
This feature is allows users to add extra label metadata to one-off containers. As this can interfere with Dokku internals if they shadow labels used by plugins, care should be taken to avoid the `com.dokku` or `org.label-schema` namespace.
Also proper name run containers so they don't get random names from docker...
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.
Often-times, we will want to have the container inspect output for debugging purposes, but this process is:
- error prone, as the user needs to know what their containers are
- potentially insecure, as the output must be sanitized of sensitive data
Instead of making users wade through this process, we provide a helper `ps:inspect` command, that can be used to diagnose problems associated with containers that may or may not exist for an application.
This can be useful in cases where a developer wishes to see what error messages are available for a failed deploy, but does not wish to spelunk around `docker ps -a` output.
Note that the logs are not made available once a further deploy is triggered, or after the containers have been garbage collected.
