github/woodpecker
1
0
Fork 0
mirror of https://github.com/woodpecker-ci/woodpecker.git synced 2026-04-15 01:41:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

Independently evaluate status filter and support on workflows (#6183)

Browse Source 
fix https://github.com/woodpecker-ci/woodpecker/issues/6161

And also allow `when.status` at workflow level. `runs_on` is deprecated then.


Co-authored-by: 6543 <6543@obermui.de>
This commit is contained in:
qwerty287
2026-03-02 17:37:37 +01:00
committed by GitHub
parent 480f673ff7
commit 39a7ebda75
13 changed files with 100 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/docs/20-usage/20-workflow-syntax.md
View File

@@ -350,6 +350,18 @@ There are use cases for executing steps on failure, such as sending notification
+ - status: [ success, failure ]
```
The filter is aware of the other filters. If you want to run on failures if the event is `tag`, but if it's a `pull_request`, run it on both success and failure:
```diff
when:
+ - event: tag
+ status: [ failure ]
+ - event: pull_request
+ status: [ success, failure ]
```
If there's no matching filter at all or all matching filters don't have set `status`, it will use the default, which means it runs on success only. In the example above this will happen if the event is neither `tag` nor `pull_request`.
#### `platform`
:::note
@@ -761,10 +773,6 @@ The workflow now triggers on `main`, but also if the target branch of a pull req
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`
Workflows that should run even on failure should set the `runs_on` tag. See [here](./25-workflows.md#flow-control) for an example.
## Advanced network options for steps
:::warning

7
docs/docs/20-usage/25-workflows.md
View File

@@ -97,7 +97,7 @@ The name for a `depends_on` entry is the filename without the path, leading dots
+ - test
```
Workflows that need to run even on failures should set the `runs_on` tag.
Workflows that need to run even on failures should set the `status` filter.
```diff
steps:
@@ -109,9 +109,12 @@ Workflows that need to run even on failures should set the `runs_on` tag.
depends_on:
- deploy
+runs_on: [ success, failure ]
+when:
+ - status: [ success, failure ]
```
This works just like the [`status` filter for steps](./20-workflow-syntax.md#status).
:::info
Some workflows don't need the source code, like creating a notification on failure.
Read more about `skip_clone` at [pipeline syntax](./20-workflow-syntax.md#skip_clone)