Update Documentation (fix diffs and add settings) (#569)

* Add migration guide for plugin settings

* Update screenshot snippets

* Adjust plugin settings

* Fix diff insertion

Co-authored-by: John Olheiser <john.olheiser@gmail.com>
This commit is contained in:
6543 2021-12-06 18:18:53 +01:00 committed by GitHub
parent 71b9179078
commit 7fb9191cce
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
10 changed files with 180 additions and 162 deletions

View file

@ -111,18 +111,15 @@ See [when](#step-when---step-conditional-execution) above to understand all the
Example targeting a specific platform:
```diff
pipeline:
build:
image: golang
commands:
- go build
- go test
-when:
-platform: [ linux/arm* ]
pipeline:
build:
image: golang
commands:
- go build
- go test
+when:
+ platform: [ linux/arm* ]
```
Assuming we have two agents, one `arm` and one `amd64`. Previously this pipeline would have executed on **either agent**, as Woodpecker is not fussy about where it runs the pipelines.
@ -134,38 +131,37 @@ This can be utilised in conjunction with other when blocks as well.
Example `when` pipeline & step block:
```yml
pipeline:
build:
image: golang
commands:
- go build
- go test
publish:
image: plugins/docker
repo: foo/bar
+when:
+tag: release*
```diff
pipeline:
build:
image: golang
commands:
- go build
- go test
publish:
image: plugins/docker
settings:
repo: foo/bar
+ when:
+ tag: release*
+when:
+ platform: [ linux/arm* ]
```
### `platform`
To configure your pipeline to select an agent with a specific platform, you can use `platform` key.
```diff
+platform: linux/arm64
pipeline:
build:
image: golang
commands:
- go build
- go test
pipeline:
build:
image: golang
commands:
- go build
- go test
```
### Skip Commits
@ -190,12 +186,12 @@ Every step of your pipeline executes arbitrary commands inside a specified docke
The associated commit of a current pipeline run is checked out with git to a workspace which is mounted to every step of the pipeline as the working directory.
```diff
pipeline:
backend:
image: golang
commands:
+ - go build
+ - go test
pipeline:
backend:
image: golang
commands:
+ - go build
+ - go test
```
### File changes are incremental
@ -221,20 +217,20 @@ pipeline:
Woodpecker uses Docker images for the build environment, for plugins and for service containers. The image field is exposed in the container blocks in the Yaml:
```diff
pipeline:
build:
+ image: golang:1.6
commands:
- go build
- go test
publish:
+ image: plugins/docker
repo: foo/bar
services:
database:
+ image: mysql
pipeline:
build:
+ image: golang:1.6
commands:
- go build
- go test
publish:
+ image: plugins/docker
repo: foo/bar
services:
database:
+ image: mysql
```
Woodpecker supports any valid Docker image from any Docker registry:
@ -250,10 +246,10 @@ image: index.docker.io/library/golang:1.7
Woodpecker does not automatically upgrade docker images. Example configuration to always pull the latest image when updates are available:
```diff
pipeline:
build:
image: golang:latest
+ pull: true
pipeline:
build:
image: golang:latest
+ pull: true
```
#### Images from private registries
@ -265,12 +261,12 @@ These credentials are never exposed to your pipeline, which means they cannot be
Example configuration using a private image:
```diff
pipeline:
build:
+ image: gcr.io/custom/golang
commands:
- go build
- go test
pipeline:
build:
+ image: gcr.io/custom/golang
commands:
- go build
- go test
```
Woodpecker matches the registry hostname to each image in your yaml. If the hostnames match, the registry credentials are used to authenticate to your registry and pull the image. Note that registry credentials are used by the Woodpecker agent and are never exposed to your build containers.
@ -302,12 +298,12 @@ For specific details on configuring access to Google Container Registry, please
Commands of every pipeline step are executed serially as if you would enter them into your local shell.
```diff
pipeline:
backend:
image: golang
commands:
+ - go build
+ - go test
pipeline:
backend:
image: golang
commands:
+ - go build
+ - go test
```
There is no magic here. The above commands are converted to a simple shell script. The commands in the above example are roughly converted to the below script:
@ -353,23 +349,23 @@ Woodpecker supports parallel step execution for same-machine fan-in and fan-out.
Example parallel configuration:
```diff
pipeline:
backend:
+ group: build
image: golang
commands:
- go build
- go test
frontend:
+ group: build
image: node
commands:
- npm install
- npm run test
- npm run build
publish:
image: plugins/docker
repo: octocat/hello-world
pipeline:
backend:
+ group: build
image: golang
commands:
- go build
- go test
frontend:
+ group: build
image: node
commands:
- npm install
- npm run test
- npm run build
publish:
image: plugins/docker
repo: octocat/hello-world
```
In the above example, the `frontend` and `backend` steps are executed in parallel. The pipeline runner will not execute the `publish` step until the group completes.
@ -403,31 +399,31 @@ The workspace can be customized using the workspace block in the Yaml file:
+ base: /go
+ path: src/github.com/octocat/hello-world
pipeline:
build:
image: golang:latest
commands:
- go get
- go test
pipeline:
build:
image: golang:latest
commands:
- go get
- go test
```
The base attribute defines a shared base volume available to all pipeline steps. This ensures your source code, dependencies and compiled binaries are persisted and shared between steps.
```diff
workspace:
+ base: /go
path: src/github.com/octocat/hello-world
pipeline:
deps:
image: golang:latest
commands:
- go get
- go test
build:
image: node:latest
commands:
- go build
workspace:
+ base: /go
path: src/github.com/octocat/hello-world
pipeline:
deps:
image: golang:latest
commands:
- go get
- go test
build:
image: node:latest
commands:
- go build
```
This would be equivalent to the following docker commands:
@ -442,9 +438,9 @@ docker run --volume=my-named-volume:/go node:latest
The path attribute defines the working directory of your build. This is where your code is cloned and will be the default working directory of every step in your build process. The path must be relative and is combined with your base path.
```diff
workspace:
base: /go
+ path: src/github.com/octocat/hello-world
workspace:
base: /go
+ path: src/github.com/octocat/hello-world
```
```text
@ -466,22 +462,23 @@ Woodpecker automatically configures a default clone step if not explicitly defin
+clone:
+ git:
+ image: woodpeckerci/plugin-git
pipeline:
build:
image: golang
commands:
- go build
- go test
pipeline:
build:
image: golang
commands:
- go build
- go test
```
Example configuration to override depth:
```diff
clone:
git:
image: woodpeckerci/plugin-git
+ depth: 50
clone:
git:
image: woodpeckerci/plugin-git
+ settings:
+ depth: 50
```
Example configuration to use a custom clone plugin:
@ -495,10 +492,11 @@ clone:
Example configuration to clone Mercurial repository:
```diff
clone:
hg:
+ image: plugins/hg
+ path: bitbucket.org/foo/bar
clone:
hg:
+ image: plugins/hg
+ settings:
+ path: bitbucket.org/foo/bar
```
#### Git Submodules
@ -506,21 +504,22 @@ clone:
To use the credentials that cloned the repository to clone it's submodules, update `.gitmodules` to use `https` instead of `git`:
```diff
[submodule "my-module"]
path = my-module
- url = git@github.com:octocat/my-module.git
+ url = https://github.com/octocat/my-module.git
[submodule "my-module"]
path = my-module
-url = git@github.com:octocat/my-module.git
+url = https://github.com/octocat/my-module.git
```
To use the ssh git url in `.gitmodules` for users cloning with ssh, and also use the https url in Woodpecker, add `submodule_override`:
```diff
clone:
git:
image: woodpeckerci/plugin-git
recursive: true
+ submodule_override:
+ my-module: https://github.com/octocat/my-module.git
clone:
git:
image: woodpeckerci/plugin-git
settings:
recursive: true
+ submodule_override:
+ my-module: https://github.com/octocat/my-module.git
pipeline:
...
@ -533,17 +532,17 @@ Woodpecker gives the ability to configure privileged mode in the Yaml. You can u
> Privileged mode is only available to trusted repositories and for security reasons should only be used in private environments. See [project settings](/docs/usage/project-settings#trusted) to enable trusted mode.
```diff
pipeline:
build:
image: docker
environment:
- DOCKER_HOST=tcp://docker:2375
commands:
- docker --tls=false ps
services:
docker:
image: docker:dind
command: [ "--storage-driver=vfs", "--tls=false" ]
+ privileged: true
pipeline:
build:
image: docker
environment:
- DOCKER_HOST=tcp://docker:2375
commands:
- docker --tls=false ps
services:
docker:
image: docker:dind
command: [ "--storage-driver=vfs", "--tls=false" ]
+ privileged: true
```

View file

@ -12,7 +12,8 @@ Example conditional execution by branch:
pipeline:
slack:
image: plugins/slack
channel: dev
settings:
channel: dev
+ when:
+ branch: master
```
@ -90,7 +91,8 @@ There are use cases for executing pipeline steps on failure, such as sending not
pipeline:
slack:
image: plugins/slack
channel: dev
settings:
channel: dev
+ when:
+ status: [ success, failure ]
```

View file

@ -146,7 +146,8 @@ Example commit substitution:
pipeline:
docker:
image: plugins/docker
+ tags: ${CI_COMMIT_SHA}
settings:
+ tags: ${CI_COMMIT_SHA}
```
Example tag substitution:
@ -155,7 +156,8 @@ Example tag substitution:
pipeline:
docker:
image: plugins/docker
+ tags: ${CI_COMMIT_TAG}
settings:
+ tags: ${CI_COMMIT_TAG}
```
## String Operations
@ -182,7 +184,8 @@ Example variable substitution with substring:
pipeline:
docker:
image: plugins/docker
+ tags: ${CI_COMMIT_SHA:0:8}
settings:
+ tags: ${CI_COMMIT_SHA:0:8}
```
Example variable substitution strips `v` prefix from `v.1.0.0`:
@ -191,5 +194,6 @@ Example variable substitution strips `v` prefix from `v.1.0.0`:
pipeline:
docker:
image: plugins/docker
+ tags: ${CI_COMMIT_TAG##v}
settings:
+ tags: ${CI_COMMIT_TAG##v}
```

View file

@ -16,12 +16,14 @@ pipeline:
publish:
image: plugins/docker
repo: foo/bar
tags: latest
settings:
repo: foo/bar
tags: latest
notify:
image: plugins/slack
channel: dev
settings:
channel: dev
```
## Plugin Isolation

View file

@ -10,10 +10,11 @@ The below example demonstrates how we might configure a webhook plugin in the Ya
pipeline:
webhook:
image: foo/webhook
url: http://foo.com
method: post
body: |
hello world
settings:
url: http://foo.com
method: post
body: |
hello world
```
## Write the logic

View file

@ -1,6 +1,6 @@
# Project settings
As the owner of a project in Woodpecker you can change some project related settings via the Webinterface.
As the owner of a project in Woodpecker you can change project related settings via the web interface.
![project settings](./project-settings.png)
@ -10,7 +10,7 @@ The path to the pipeline config file or folder. By default it is left empty whic
## Repository hooks
Your Version-Control-System will notify Woodpecker about some events via webhooks. If you want your pipeline to only run on specific webhooks, you can check them by this setting.
Your Version-Control-System will notify Woodpecker about events via webhooks. If you want your pipeline to only run on specific webhooks, you can check them with this setting.
## Project settings

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 128 KiB

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 154 KiB

After

Width:  |  Height:  |  Size: 25 KiB

View file

@ -51,7 +51,17 @@ Some versions need some changes to the server configuration or the pipeline conf
- `/var/lib/drone/drone.sqlite` -> `/var/lib/woodpecker/woodpecker.sqlite`
- `drone.sqlite` -> `woodpecker.sqlite`
- ...
- Plugin Settings moved into `settings` section:
```diff
pipline:
something:
image: my/plugin
- setting1: foo
- setting2: bar
+ settings:
+ setting1: foo
+ setting2: bar
```
## 0.14.0