github/dokku
0
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

docs: update markdownlint rules for better formatting

Browse Source
This commit is contained in:
Jose Diaz-Gonzalez
2023-08-19 13:29:12 -04:00
parent b87d619b23
commit 5dd78e2b86
44 changed files with 243 additions and 215 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/deployment/builders/builder-management.md
View File

@@ -131,14 +131,14 @@ dokku builder:report node-js-app --builder-selected
To create a custom builder, the following triggers must be implemented:
- `builder-build`:
- arguments: `BUILDER_TYPE` `APP` `SOURCECODE_WORK_DIR`
- description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
- arguments: `BUILDER_TYPE` `APP` `SOURCECODE_WORK_DIR`
- description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
- `builder-detect`:
- arguments: `APP` `SOURCECODE_WORK_DIR`
- description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
- arguments: `APP` `SOURCECODE_WORK_DIR`
- description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
- `builder-release`:
- arguments: `BUILDER_TYPE` `APP` `IMAGE_AG`
- description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
- arguments: `BUILDER_TYPE` `APP` `IMAGE_AG`
- description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
Custom plugins names _must_ have the prefix `builder-` or builder overriding via `builder:set` may not function as expected.

18
docs/deployment/builders/cloud-native-buildpacks.md
View File

@@ -28,25 +28,27 @@ Builds will proceed with the `pack` cli for the app from then on.
As this functionality is highly experimental, there are a number of caveats. Please note that not all issuesare listed below.
- Specifying specific buildpacks is not currently possible.
- A future release will add support for specifying buildpacks via the `buildpacks` plugin.
- A future release will add support for specifying buildpacks via the `buildpacks` plugin.
- There is currently no way to specify extra arguments for `pack` cli invocations.
- A future release will add support for injecting extra arguments during the build process.
- A future release will add support for injecting extra arguments during the build process.
- The default process type is `web`.
- Build cache is stored in Docker volumes instead of on disk. As such, `repo:purge-cache` currently has no effect.
- A future version will add integration with the `repo` plugin.
- A future version will add integration with the `repo` plugin.
- `pack` is not currently included with Dokku, nor is it added as a package dependency.
- A future version will include it as a package dependency.
- A future version will include it as a package dependency.
### Detection
This builder will be auto-detected in either the following cases:
- The `DOKKU_CNB_EXPERIMENTAL` app environment variable is set to `1`.
```shell
dokku config:set --no-restart node-js-app DOKKU_CNB_EXPERIMENTAL=1
```
```shell
dokku config:set --no-restart node-js-app DOKKU_CNB_EXPERIMENTAL=1
```
- A `project.toml` file exists in the root of the app repository.
- This file is consumed by `pack-cli` and used to describe how the app is built.
- This file is consumed by `pack-cli` and used to describe how the app is built.
The builder can also be specified via the `builder:set` command:

8
docs/deployment/builders/herokuish-buildpacks.md
View File

@@ -22,9 +22,9 @@ builder-herokuish:set <app> <key> (<value>) # Set or clear a builder-herokuish p
Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, though this may be overridden by committing a valid `Dockerfile` to the root of your repository and pushing the repository to your Dokku installation. To avoid this automatic `Dockerfile` deployment detection, you may do one of the following:
- Set a `BUILDPACK_URL` environment variable
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
- Create a `.buildpacks` file in the root of your repository.
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
This page will cover usage of the `buildpacks` plugin.
@@ -35,9 +35,9 @@ This page will cover usage of the `buildpacks` plugin.
This builder will be auto-detected in either the following cases:
- The `BUILDPACK_URL` app environment variable is set.
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
- This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
- A `.buildpacks` file exists in the root of the app repository.
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
- This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
The builder can also be specified via the `builder:set` command: