mirror of
https://github.com/woodpecker-ci/woodpecker.git
synced 2024-12-14 12:36:30 +00:00
140 lines
4.6 KiB
Markdown
140 lines
4.6 KiB
Markdown
|
# Creating plugins
|
||
|
|
||
|
Creating a new plugin is simple: Build a Docker container which uses your plugin logic as the ENTRYPOINT.
|
||
|
|
||
|
## Settings
|
||
|
|
||
|
To allow users to configure the behavior of your plugin, you should use `settings:`.
|
||
|
|
||
|
These are passed to your plugin as uppercase env vars with a `PLUGIN_` prefix.
|
||
|
Using a setting like `url` results in an env var named `PLUGIN_URL`.
|
||
|
|
||
|
Characters like `-` are converted to an underscore (`_`). `some_String` gets `PLUGIN_SOME_STRING`.
|
||
|
CamelCase is not respected, `anInt` get `PLUGIN_ANINT`.
|
||
|
|
||
|
### Basic settings
|
||
|
|
||
|
Using any basic YAML type (scalar) will be converted into a string:
|
||
|
|
||
|
| Setting | Environment value |
|
||
|
| -------------------- | ---------------------------- |
|
||
|
| `some-bool: false` | `PLUGIN_SOME_BOOL="false"` |
|
||
|
| `some_String: hello` | `PLUGIN_SOME_STRING="hello"` |
|
||
|
| `anInt: 3` | `PLUGIN_ANINT="3"` |
|
||
|
|
||
|
### Complex settings
|
||
|
|
||
|
It's also possible to use complex settings like this:
|
||
|
|
||
|
```yaml
|
||
|
steps:
|
||
|
- name: plugin
|
||
|
image: foo/plugin
|
||
|
settings:
|
||
|
complex:
|
||
|
abc: 2
|
||
|
list:
|
||
|
- 2
|
||
|
- 3
|
||
|
```
|
||
|
|
||
|
Values like this are converted to JSON and then passed to your plugin. In the example above, the environment variable `PLUGIN_COMPLEX` would contain `{"abc": "2", "list": [ "2", "3" ]}`.
|
||
|
|
||
|
### Secrets
|
||
|
|
||
|
Secrets should be passed as settings too. Therefore, users should use [`from_secret`](../40-secrets.md#use-secrets-in-settings-and-environment).
|
||
|
|
||
|
## Plugin library
|
||
|
|
||
|
For Go, we provide a plugin library you can use to get easy access to internal env vars and your settings. See <https://codeberg.org/woodpecker-plugins/go-plugin>.
|
||
|
|
||
|
## Metadata
|
||
|
|
||
|
In your documentation, you can use a Markdown header to define metadata for your plugin. This data is used by [our plugin index](/plugins).
|
||
|
|
||
|
Supported metadata:
|
||
|
|
||
|
- `name`: The plugin's full name
|
||
|
- `icon`: URL to your plugin's icon
|
||
|
- `description`: A short description of what it's doing
|
||
|
- `author`: Your name
|
||
|
- `tags`: List of keywords (e.g. `[git, clone]` for the clone plugin)
|
||
|
- `containerImage`: name of the container image
|
||
|
- `containerImageUrl`: link to the container image
|
||
|
- `url`: homepage or repository of your plugin
|
||
|
|
||
|
If you want your plugin to be listed in the index, you should add as many fields as possible, but only `name` is required.
|
||
|
|
||
|
## Example plugin
|
||
|
|
||
|
This provides a brief tutorial for creating a Woodpecker webhook plugin, using simple shell scripting, to make HTTP requests during the build pipeline.
|
||
|
|
||
|
### What end users will see
|
||
|
|
||
|
The below example demonstrates how we might configure a webhook plugin in the YAML file:
|
||
|
|
||
|
```yaml
|
||
|
steps:
|
||
|
- name: webhook
|
||
|
image: foo/webhook
|
||
|
settings:
|
||
|
url: https://example.com
|
||
|
method: post
|
||
|
body: |
|
||
|
hello world
|
||
|
```
|
||
|
|
||
|
### Write the logic
|
||
|
|
||
|
Create a simple shell script that invokes curl using the YAML configuration parameters, which are passed to the script as environment variables in uppercase and prefixed with `PLUGIN_`.
|
||
|
|
||
|
```bash
|
||
|
#!/bin/sh
|
||
|
|
||
|
curl \
|
||
|
-X ${PLUGIN_METHOD} \
|
||
|
-d ${PLUGIN_BODY} \
|
||
|
${PLUGIN_URL}
|
||
|
```
|
||
|
|
||
|
### Package it
|
||
|
|
||
|
Create a Dockerfile that adds your shell script to the image, and configures the image to execute your shell script as the main entrypoint.
|
||
|
|
||
|
```dockerfile
|
||
|
# please pin the version, e.g. alpine:3.19
|
||
|
FROM alpine
|
||
|
ADD script.sh /bin/
|
||
|
RUN chmod +x /bin/script.sh
|
||
|
RUN apk -Uuv add curl ca-certificates
|
||
|
ENTRYPOINT /bin/script.sh
|
||
|
```
|
||
|
|
||
|
Build and publish your plugin to the Docker registry. Once published, your plugin can be shared with the broader Woodpecker community.
|
||
|
|
||
|
```shell
|
||
|
docker build -t foo/webhook .
|
||
|
docker push foo/webhook
|
||
|
```
|
||
|
|
||
|
Execute your plugin locally from the command line to verify it is working:
|
||
|
|
||
|
```shell
|
||
|
docker run --rm \
|
||
|
-e PLUGIN_METHOD=post \
|
||
|
-e PLUGIN_URL=https://example.com \
|
||
|
-e PLUGIN_BODY="hello world" \
|
||
|
foo/webhook
|
||
|
```
|
||
|
|
||
|
## Best practices
|
||
|
|
||
|
- Build your plugin for different architectures to allow many users to use them.
|
||
|
At least, you should support `amd64` and `arm64`.
|
||
|
- Provide binaries for users using the `local` backend.
|
||
|
These should also be built for different OS/architectures.
|
||
|
- Use [built-in env vars](../50-environment.md#built-in-environment-variables) where possible.
|
||
|
- Do not use any configuration except settings (and internal env vars). This means: Don't require using [`environment`](../50-environment.md) and don't require specific secret names.
|
||
|
- Add a `docs.md` file, listing all your settings and plugin metadata ([example](https://github.com/woodpecker-ci/plugin-git/blob/main/docs.md)).
|
||
|
- Add your plugin to the [plugin index](/plugins) using your `docs.md` ([the example above in the index](https://woodpecker-ci.org/plugins/Git%20Clone)).
|