Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

It is not clear what values belong to the conclusion or the status fields of a workflow run

オープン
#1,634 コメント 11 件 リアクション 17 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
52/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
openapi
領域
api, documentation

調査の方向性

「List workflow runs for a workflow」エンドポイントの OpenAPI description から始め、issue で引用されている「Get a workflow run」エンドポイントとその status パラメーターを比較してください。どの値が status に属し、どの値が conclusion に属するのかを明確にし、conclusion をクエリで指定できるように受け取れる表現を削除してください。対象エンドポイントのドキュメントでは、2 つのフィールドとその使用方法が曖昧にならないようにしてください。

索引モデルが issue の本文から書いたものです。

説明

content rest-schema waiting for review
Code of Conduct
What article on docs.github.com is affected?

https://docs.github.com/en/rest/actions/workflow-runs#list-workflow-runs-for-a-workflow

list-workflow-runs-for-a-workflow-github-api-call

What changes are you suggesting?
Issue 1.

The following values presented on the article linked above:

Can be one of: completed, action_required, cancelled, failure, neutral, skipped, stale, success, timed_out, in_progress, queued, requested, waiting

Are not clearly separated between status and conclusion categories.

The first two lines make the whole paragraph ambiguous:

Returns workflow runs with the check run status or conclusion that you specify. For example, a conclusion can be success or a status can be in_progress

Which seem to indicate that conclusion could also be a query parameter

Expected outcome

Can you please redact the {status} parameter documentation of the API call (see article section):
https://api.github.com/repos/OWNER/REPO/actions/workflows/WORKFLOW_ID/runs

And separate the values in the list above by assigning them to status and conclusion respectively.

Issue 2.

It also would be great to make sure that conclusion is not misrepresented as a query parameter for that specific API call on the first sentence by using ambiguous language.

Returns workflow runs with the check run status or conclusion that you specify

As we cannot specify a conclusion value as a query parameter, the result is the same as querying for all runs in the workflow. And there's no conclusion parameter indicated.

For example, for a cancelled workflow run the payload contains the following:

Query:
https://docs.github.com/en/rest/actions/workflow-runs#get-a-workflow-run

Response:

"status": "completed",
"conclusion": "cancelled",

Use case

We would like to take a 2 step process where:

  1. We find out the status of an specific workflow run
  2. Report and FAIL/SUCCEED based on the value in the conclusion

See additional information for more details.

Additional information

It is confusing to tell what to query for in the returned JSON payload when looking at an specific workflow run by id to find out if it was completed or not, since the only text that has an exhaustive list of statuses and conclusions is in the affected article and that text is ambiguous.

This is the query I'm actually using with short polling, the use case is that given a workflow run id, find out when it is completed and report the conclusion by calling this endpoint.

https://api.github.com/repos/OWNER/REPO/actions/runs/RUN_ID
get-a-workflow-run-github-api-call

According to this API call:
https://docs.github.com/en/rest/actions/workflow-runs#get-a-workflow-run

Also, as you can see on the Response schema sections of each api call section the only example given is complete.

P.S.
Instead of recurring to the docs, I had to go outside of the Github docs to find out the disambiguation information I needed:
https://tabris.com/observing-workflow-run-status-on-github/

Value of the status property can be one of: “queued”, “in_progress”, or “completed”. When it’s “completed,” it makes sense to check if it finished successfully. We need a value of the conclusion property. Can be one of the “success”, “failure”, “neutral”, “cancelled”, “skipped”, “timed_out”, or “action_required”.

主要言語
言語のデータがありません
スター
1.6k
フォーク
342
平均マージ
2時間 23分
マージ済み PR(30日)
57

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/rest-api-description のほかの issue

github/rest-api-description の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。