4b5e01365c
* Use in_progress workflow_job example, not queued ### tl;dr This changes the example `workflow_job` payload to be an `in_progress` event instead of `queued` event. ### why In #22174, I added some keys to the example workflow_job json. This was correct, but by adding non-null _values_, **I introduced a subtle bug**. It's a bug because a `queued` workflow is—by definition—_not_ yet assigned to a runner. So all the `runner_*` attributes will be `null` in the real world. After the workflow becomes `in_progress`, all the values are guaranteed to exist. So let's change the example to be an `in_progress` event, since it's a better example for documentation. * Explain more about the runner_* attributes in "workflow_job_properties.md" * Consistentize naming Co-authored-by: Martin Lopes <martin389@github.com> Co-authored-by: hubwriter <hubwriter@github.com>
1.4 KiB
1.4 KiB
| Key | Type | Description |
|---|---|---|
action |
string |
The action performed. Can be one of:
|
workflow_job |
object |
The workflow job. Many workflow_job keys, such as head_sha, conclusion, and started_at are the same as those in a check_run object. |
workflow_job[status] |
string |
The current status of the job. Can be queued, in_progress, or completed. |
workflow_job[labels] |
array |
Custom labels for the job. Specified by the "runs-on" attribute in the workflow YAML. |
workflow_job[runner_id] |
integer |
The ID of the runner that is running this job. This will be null as long as workflow_job[status] is queued. |
workflow_job[runner_name] |
string |
The name of the runner that is running this job. This will be null as long as workflow_job[status] is queued. |
workflow_job[runner_group_id] |
integer |
The ID of the runner group that is running this job. This will be null as long as workflow_job[status] is queued. |
workflow_job[runner_group_name] |
string |
The name of the runner group that is running this job. This will be null as long as workflow_job[status] is queued. |