WIP: New event pull request metadata #5214
Conversation
|
as alternative to #5155 ... for now i try to implement the gitea part only and then we can decide if we wana have a meta event or single events for each ... |
|
I will now stop working on it till it was decided to go with option B ... or if with A ... we can close this here ref: #5155 (comment) Asap B was elected I'll finish this work as high priority ... |
| | `CI_PIPELINE_NUMBER` | pipeline number | `8` | | ||
| | `CI_PIPELINE_PARENT` | number of parent pipeline | `0` | | ||
| | `CI_PIPELINE_EVENT` | pipeline event (see [`event`](../20-usage/20-workflow-syntax.md#event)) | `push`, `pull_request`, `pull_request_closed`, `pull_request_metadata`, `tag`, `release`, `manual`, `cron` | | ||
| | `CI_PIPELINE_EVENT_REASON` | exact reason `pull_request_metadata` event was send. it is forge instance specific and can change | `label_updated`, `milestoned`, `demilestoned`, `assigned`, `edited`, ... | |
There was a problem hiding this comment.
the nice part with this is, that we can adjust per forge independently on what a forge support and if it changes it is as per documentation adjustable :)
in short terms we try to pass through what the forge reports in the webhook what event type it was ...
There was a problem hiding this comment.
... we might document this future in the forge specific doc parts ... 👁️
This reverts commit 7e88ecc.
|
Deploying preview to https://woodpecker-ci-woodpecker-pr-5214.surge.sh |
start implementing metadata event
Sponsored by Kithara Software GmbH