[pre-commit.ci] pre-commit autoupdate (#3329)

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
This commit is contained in:
pre-commit-ci[bot] 2024-02-08 17:19:01 +01:00 committed by GitHub
parent f92f8b17a3
commit d3b57ff0e6
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
5 changed files with 25 additions and 146 deletions

View file

@ -14,10 +14,10 @@ repos:
hooks:
- id: golangci-lint
- repo: https://github.com/igorshubovych/markdownlint-cli
rev: v0.38.0
rev: v0.39.0
hooks:
- id: markdownlint
exclude: '^docs/versioned_docs/.*$'
exclude: '^(docs/versioned_docs/.*|CHANGELOG.md)$'
- repo: https://github.com/mrtazz/checkmake
rev: 0.2.2
hooks:

View file

@ -352,8 +352,12 @@ when:
- platform: [linux/*, windows/amd64]
```
<!-- markdownlint-disable no-duplicate-heading -->
#### `environment`
<!-- markdownlint-enable no-duplicate-heading -->
Execute a step for deployment events matching the target deployment environment:
```yaml
@ -556,8 +560,12 @@ git clone https://github.com/octocat/hello-world \
/go/src/github.com/octocat/hello-world
```
<!-- markdownlint-disable no-duplicate-heading -->
## `matrix`
<!-- markdownlint-enable no-duplicate-heading -->
Woodpecker has integrated support for matrix builds. Woodpecker executes a separate build task for each combination in the matrix, allowing you to build and test a single commit against multiple configurations.
For more details check the [matrix build docs](./30-matrix-workflows.md).
@ -696,26 +704,7 @@ skip_clone: true
Woodpecker gives the ability to skip whole workflows (not just steps #when---conditional-execution-1) based on certain conditions by a `when` block. If all conditions in the `when` block evaluate to true the workflow is executed, otherwise it is skipped, but treated as successful and other workflows depending on it will still continue.
### `repo`
Example conditional execution by repository:
```diff
+when:
+ repo: test/test
+
steps:
- name: slack
image: plugins/slack
settings:
channel: dev
```
### `branch`
:::note
Branch conditions are not applied to tags.
:::
For more information about the specific filters, take a look at the [step-specific `when` filters](#when---conditional-execution).
Example conditional execution by branch:
@ -730,126 +719,14 @@ Example conditional execution by branch:
channel: dev
```
The step now triggers on `main`, but also if the target branch of a pull request is `main`. Add an event condition to limit it further to pushes on main only.
The workflow now triggers on `main`, but also if the target branch of a pull request is `main`.
Execute a step if the branch is `main` or `develop`:
```yaml
when:
branch: [main, develop]
```
Execute a step if the branch starts with `prefix/*`:
```yaml
when:
branch: prefix/*
```
Execute a step using custom include and exclude logic:
```yaml
when:
branch:
include: [main, release/*]
exclude: [release/1.0.0, release/1.1.*]
```
### `event`
:::warning
Some events like the release event will be triggered for multiple actions like: releases, pre-releases and drafts. If you want to apply further filters checkout the [evaluate](#evaluate) filter and the available [environment variables](./50-environment.md#built-in-environment-variables).
:::
Execute a step if the build event is a `tag`:
```yaml
when:
event: tag
```
Execute a step if the pipeline event is a `push` to a specified branch:
```diff
when:
event: push
+ branch: main
```
Execute a step for all non-pull request events:
```yaml
when:
event: [push, tag, deployment]
```
Execute a step for all build events:
```yaml
when:
event: [push, pull_request, pull_request_closed, tag, deployment, release]
```
### `ref`
The `ref` filter compares the git reference against which the pipeline is executed.
This allows you to filter, for example, tags that must start with **v**:
```yaml
when:
event: tag
ref: refs/tags/v*
```
### `environment`
Execute a step for deployment events matching the target deployment environment:
```yaml
when:
environment: production
event: deployment
```
### `instance`
Execute a step only on a certain Woodpecker instance matching the specified hostname:
```yaml
when:
instance: stage.woodpecker.company.com
```
### `path`
:::info
Path conditions are applied only to **push** and **pull_request** events.
It is currently **only available** for GitHub, GitLab and Gitea (version 1.18.0 and newer)
:::
Execute a step only on a pipeline with certain files being changed:
```yaml
when:
path: 'src/*'
```
You can use [glob patterns](https://github.com/bmatcuk/doublestar#patterns) to match the changed files and specify if the step should run if a file matching that pattern has been changed `include` or if some files have **not** been changed `exclude`.
```yaml
when:
path:
include: ['.woodpecker/*.yaml', '*.ini']
exclude: ['*.md', 'docs/**']
ignore_message: '[ALL]'
```
:::info
Passing a defined ignore-message like `[ALL]` inside the commit message will ignore all path conditions.
:::
<!-- markdownlint-disable no-duplicate-heading -->
## `depends_on`
<!-- markdownlint-enable no-duplicate-heading -->
Woodpecker supports to define multiple workflows for a repository. Those workflows will run independent from each other. To depend them on each other you can use the [`depends_on`](./25-workflows.md#flow-control) keyword.
## `runs_on`

View file

@ -12,18 +12,16 @@ The path to the pipeline config file or folder. By default it is left empty whic
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
### Allow pull requests
## Allow pull requests
Enables handling webhook's pull request event. If disabled, then pipeline won't run for pull requests.
### Protected
## Protected
Every pipeline initiated by an webhook event needs to be approved by a project members with push permissions before being executed.
The protected option can be used as an additional review process before running potentially harmful pipelines. Especially if pipelines can be executed by third-parties through pull-requests.
### Trusted
## Trusted
If you set your project to trusted, a pipeline step and by this the underlying containers gets access to escalated capabilities like mounting volumes.
@ -33,7 +31,7 @@ Only server admins can set this option. If you are not a server admin this optio
:::
### Only inject netrc credentials into trusted containers
## Only inject netrc credentials into trusted containers
Cloning pipeline step may need git credentials. They are injected via netrc. By default, they're only injected if this option is enabled, the repo is trusted ([see above](#trusted)) or the image is a trusted clone image. If you uncheck the option, git credentials will be injected into any container in clone step.

View file

@ -48,8 +48,12 @@ You can manage encryption on server using these environment variables:
TINK uses AEAD encryption instead of simple AES and supports key rotation.
<!-- markdownlint-disable no-duplicate-heading -->
### Configuration
<!-- markdownlint-enable no-duplicate-heading -->
You can manage encryption on server using these two environment variables:
- `WOODPECKER_ENCRYPTION_TINK_KEYSET_FILE` - keyset filepath

View file

@ -34,8 +34,8 @@
| `server/forge/**` | forge lib for server to connect and handle forge specific stuff | `shared`, `server/model` |
| `server/router/**` | handle requests to REST API (and all middleware) and serve UI and WebUI config | `shared`, `../api`, `../model`, `../forge`, `../store`, `../web` |
| `server/store/**` | handle database | `server/model` |
| `server/shared/**` | TODO: move and split [#974](https://github.com/woodpecker-ci/woodpecker/issues/974) |
| `server/web/**` | server SPA |
| `server/shared/**` | TODO: move and split [#974](https://github.com/woodpecker-ci/woodpecker/issues/974) | |
| `server/web/**` | server SPA | |
- `../` = `server/`