Use correct casing for Dokku name
lowercase should only be used to refer to the binary, not the project
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
|
||||
If you create your own plugin:
|
||||
|
||||
1. Take a look at the plugins shipped with dokku and hack away!
|
||||
1. Take a look at the plugins shipped with Dokku and hack away!
|
||||
2. Check out the [list of triggers](/dokku/development/plugin-triggers) your plugin can implement.
|
||||
3. Upload your plugin to github with a repository name in form of `dokku-<name>` (e.g. `dokku-mariadb`)
|
||||
4. Edit [this page](/dokku/community/plugins/) and add a link to it.
|
||||
@@ -124,7 +124,7 @@ A few notes:
|
||||
- If your command requires that an application exists, ensure you check for it's existence in the manner prescribed above.
|
||||
- A `help` command is required, though it is allowed to be empty. Also, the command syntax will need to separated by `, ` in order to maintain columnar output alignment.
|
||||
- Commands *should* be namespaced.
|
||||
- As of 0.3.3, a catch-all should be implemented which exits with a `DOKKU_NOT_IMPLEMENTED_EXIT` code. This allows dokku to output a `command not found` message.
|
||||
- As of 0.3.3, a catch-all should be implemented which exits with a `DOKKU_NOT_IMPLEMENTED_EXIT` code. This allows Dokku to output a `command not found` message.
|
||||
- Be sure you want the "set -eo pipefail" option. Look at the following example :
|
||||
|
||||
```shell
|
||||
@@ -134,7 +134,7 @@ A few notes:
|
||||
fi
|
||||
```
|
||||
|
||||
In the case where the "user/repo" is not installed, dokku exits just before the awk command,
|
||||
In the case where the "user/repo" is not installed, Dokku exits just before the awk command,
|
||||
you will never see the message printed with echo. You just want "set -e" in this case.
|
||||
|
||||
Here is the documentation of the 'set -eo pipefail' option:
|
||||
@@ -156,4 +156,4 @@ A few notes:
|
||||
- From time to time you may want to allow other plugins access to (some of) your plugin's functionality. You can expose this by including a `functions` file in your plugin for others to source. Consider all functions in that file to be publicly accessible by other plugins. Any functions not wished to be made "public" should reside within your plugin trigger or commands files.
|
||||
- As of 0.4.0, we allow image tagging and deployment of said tagged images. Therefore, hard-coding of `$IMAGE` as `dokku/$APP` is no longer sufficient. Instead, for non `pre/post-build-*` plugins, use `get_running_image_tag()` & `get_app_image_name()` as sourced from common/functions. See the [plugin triggers](/dokku/development/plugin-triggers) doc for examples.
|
||||
- As of 0.5.0, we use container labels to help cleanup intermediate containers with `dokku cleanup`. If manually calling `docker run`, include `$DOKKU_GLOBAL_RUN_ARGS`. This will ensure you intermediate containers labeled correctly.
|
||||
- As of 0.6.0, we advise you to *not* call the dokku binary directly from within plugins. Clients using the `--app` argument are potentially broken, amongst other issues, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call dokku internal functions
|
||||
- As of 0.6.0, we advise you to *not* call the `dokku` binary directly from within plugins. Clients using the `--app` argument are potentially broken, amongst other issues, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call Dokku internal functions
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Plugin triggers
|
||||
|
||||
[Plugin triggers](https://github.com/dokku/plugn) (formerly [pluginhooks](https://github.com/progrium/pluginhook)) are a good way to jack into existing dokku infrastructure. You can use them to modify the output of various dokku commands or override internal configuration.
|
||||
[Plugin triggers](https://github.com/dokku/plugn) (formerly [pluginhooks](https://github.com/progrium/pluginhook)) are a good way to jack into existing Dokku infrastructure. You can use them to modify the output of various Dokku commands or override internal configuration.
|
||||
|
||||
Plugin triggers are simply scripts that are executed by the system. You can use any language you want, so long as the script:
|
||||
|
||||
@@ -9,7 +9,7 @@ Plugin triggers are simply scripts that are executed by the system. You can use
|
||||
|
||||
For instance, if you wanted to write a plugin trigger in PHP, you would need to have `php` installed and available on the CLI prior to plugin trigger invocation.
|
||||
|
||||
The following is an example for the `nginx-hostname` plugin trigger. It reverses the hostname that is provided to nginx during deploys. If you created an executable file named `nginx-hostname` with the following code in your plugin trigger, it would be invoked by dokku during the normal app deployment process:
|
||||
The following is an example for the `nginx-hostname` plugin trigger. It reverses the hostname that is provided to nginx during deploys. If you created an executable file named `nginx-hostname` with the following code in your plugin trigger, it would be invoked by Dokku during the normal app deployment process:
|
||||
|
||||
```shell
|
||||
#!/usr/bin/env bash
|
||||
@@ -23,11 +23,11 @@ echo "$NEW_SUBDOMAIN.$VHOST"
|
||||
|
||||
## Available plugin triggers
|
||||
|
||||
There are a number of plugin-related triggers. These can be optionally implemented by plugins and allow integration into the standard dokku setup/teardown process.
|
||||
There are a number of plugin-related triggers. These can be optionally implemented by plugins and allow integration into the standard Dokku setup/teardown process.
|
||||
|
||||
The following plugin triggers describe those available to a dokku installation. As well, there is an example for each trigger that you can use as templates for your own plugin development.
|
||||
The following plugin triggers describe those available to a Dokku installation. As well, there is an example for each trigger that you can use as templates for your own plugin development.
|
||||
|
||||
> The example plugin trigger code is not guaranteed to be implemented as in within dokkku, and are merely simplified examples. Please look at the dokku source for larger, more in-depth examples.
|
||||
> The example plugin trigger code is not guaranteed to be implemented as in within dokkku, and are merely simplified examples. Please look at the Dokku source for larger, more in-depth examples.
|
||||
|
||||
### `post-config-update`
|
||||
|
||||
@@ -63,7 +63,7 @@ echo false
|
||||
|
||||
### `check-deploy`
|
||||
|
||||
- Description: Allows you to run checks on a deploy before dokku allows the container to handle requests.
|
||||
- Description: Allows you to run checks on a deploy before Dokku allows the container to handle requests.
|
||||
- Invoked by: `dokku deploy`
|
||||
- Arguments: `$APP $CONTAINER_ID $PROC_TYPE $PORT $IP`
|
||||
- Example:
|
||||
@@ -312,7 +312,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
|
||||
|
||||
```shell
|
||||
#!/usr/bin/env bash
|
||||
# Sets the hostname of the dokku server
|
||||
# Sets the hostname of the Dokku server
|
||||
# based on the output of `hostname -f`
|
||||
|
||||
set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
|
||||
@@ -778,7 +778,7 @@ dokku hg-build $APP $REV
|
||||
|
||||
```shell
|
||||
#!/bin/bash
|
||||
# Gives dokku the ability to support multiple branches for a given service
|
||||
# Gives Dokku the ability to support multiple branches for a given service
|
||||
# Allowing you to have multiple staging environments on a per-branch basis
|
||||
|
||||
reference_app=$1
|
||||
@@ -865,7 +865,7 @@ sudo BUILD_STACK=true make install
|
||||
|
||||
### `user-auth`
|
||||
|
||||
This is a special plugin trigger that is executed on *every* command run. As dokku sometimes internally invokes the `dokku` command, special care should be taken to properly handle internal command redirects.
|
||||
This is a special plugin trigger that is executed on *every* command run. As Dokku sometimes internally invokes the `dokku` command, special care should be taken to properly handle internal command redirects.
|
||||
|
||||
Note that the trigger should exit as follows:
|
||||
|
||||
@@ -882,7 +882,7 @@ sshcommand acl-add dokku NAME < $PATH_TO_SSH_KEY
|
||||
|
||||
Note that the `NAME` value is set at the first ssh key match. If an ssh key is set in the `/home/dokku/.ssh/authorized_keys` multiple times, the first match will decide the value.
|
||||
|
||||
- Description: Allows you to deny access to a dokku command by either ssh user or associated ssh-command NAME user.
|
||||
- Description: Allows you to deny access to a Dokku command by either ssh user or associated ssh-command NAME user.
|
||||
- Invoked by `dokku`
|
||||
- Arguments: `$SSH_USER $SSH_NAME $DOKKU_COMMAND`
|
||||
- Example:
|
||||
|
||||
@@ -39,9 +39,9 @@ At the moment, tags need not be signed, though that may change in the future.
|
||||
|
||||
## Debian Packages
|
||||
|
||||
The `build` target in the dokku `Vagrantfile` creates debian packages for dokku at a point in time. The version will be based upon the latest local tag - you may create your own, internal tags/releases if that is so desired.
|
||||
The `build` target in the Dokku `Vagrantfile` creates debian packages for Dokku at a point in time. The version will be based upon the latest local tag - you may create your own, internal tags/releases if that is so desired.
|
||||
|
||||
Debian package information is held in the `debian` directory of the dokku project.
|
||||
Debian package information is held in the `debian` directory of the Dokku project.
|
||||
|
||||
For the public project, releases should be pushed to packagecloud.io *after* a tag is created but *before* said tag is pushed to github. The following may be the release workflow:
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ While we do provide official packages for a variety of platforms, as our test su
|
||||
|
||||
## Local Test Execution
|
||||
|
||||
- Setup dokku in a [vagrant vm](/dokku/getting-started/install/vagrant)
|
||||
- Setup Dokku in a [vagrant vm](/dokku/getting-started/install/vagrant)
|
||||
- Run the following to setup tests and execute them:
|
||||
|
||||
```shell
|
||||
@@ -29,7 +29,7 @@ While we do provide official packages for a variety of platforms, as our test su
|
||||
# execute the entire test suite (linter, bats tests, and app deployment tests)
|
||||
make test
|
||||
|
||||
# run linter & update vagrant dokku install from local git clone
|
||||
# run linter & update vagrant Dokku install from local git clone
|
||||
make lint copyfiles
|
||||
|
||||
# execute all bats tests
|
||||
@@ -45,4 +45,4 @@ Additionally you may run a specific app deployment tests with a target similar t
|
||||
make deploy-test-nodejs-express
|
||||
```
|
||||
|
||||
For a full list of test make targets check out `tests.mk` in the root of the dokku repository.
|
||||
For a full list of test make targets check out `tests.mk` in the root of the Dokku repository.
|
||||
|
||||
Reference in New Issue
Block a user