This change allows users to specify a custom nginx.conf.sigil that can expose non-web process types to the outside world in addition to the web process type.
Closes#3258
Containers can be attached:
- after they are created, but before they are started
- after a successful deploy, but before the proxy reloads
This allows folks to have flexibility around when they would like a container to be made available to a network.
The IMAGE_TAG is not always available, while the IMAGE_SOURCE_TYPE is. Since the point of these triggers was to unify the argument passed and make it easier to interact with them, this version makes more sense.
Closes#3780
After a `dokku run` container is created and started, this plugin trigger will allow developers to run auxiliary commands in response to that container.
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.
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.
This reduces duplication and allows users to rely on global arguments to generate most labels needed.
The 'commit' command cannot have global arguments because the whitespace within the label change breaks string-based interpolation, and shell arrays cannot be exported.
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 will allow us to kill stale proxy configuration within apps, which is critical during application renames.
- redirect rmdir output to dev-null
- trigger a proxy-clear-config (new trigger) when renaming an application
- The configuration will be rebuilt during the later `ps_rebuild`
Closes#3231
This is useful in cases where the app url has some "interesting" structure - such as a subdomain or scheme change - for a specific installation.
Closes#3160
This allows users to quickly show the state of any configured application, as well as the state of their server. In doing so, we make it easy for them to provide information necessary for debugging in a single command.
