It is not clear what values belong to the conclusion or the status fields of a workflow run
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 52/100
- Loại issue
- Tài liệu
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- openapi
- Lĩnh vực
- api, documentation
Hướng nghiên cứu
Bắt đầu với mô tả OpenAPI cho endpoint “List workflow runs for a workflow” và so sánh tham số status của endpoint này với endpoint “Get a workflow run” được trích dẫn trong issue. Làm rõ giá trị nào thuộc về status và giá trị nào thuộc về conclusion, đồng thời loại bỏ cách diễn đạt ngụ ý rằng conclusion có thể được truy vấn; tài liệu của endpoint bị ảnh hưởng phải làm rõ ràng hai trường và cách sử dụng chúng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Code of Conduct
- I have read and agree to the GitHub Docs project's 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
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:
- We find out the status of an specific workflow run
- 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
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”.
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 1.6k
- Fork
- 342
- Merge trung bình
- 2 giờ 23 phút
- Pull request đã merge (30 ngày)
- 57
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/rest-api-description
-
feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
github/rest-api-description#7220 ·
-
feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
github/rest-api-description#7201 ·
-
feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
github/rest-api-description#7163 ·
-
Runner deprecations: registration_deprecates_at is declared on the response but never returned Đang mởfeature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
github/rest-api-description#7162 ·
-
feature
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
github/rest-api-description#7135 ·
Tất cả issue của github/rest-api-description
Issue tương tự
-
Area: Excel support
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
orbeon/orbeon-forms#7893 ·
-
essnmx good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
yeti-platform/yeti#1380 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
modelcontextprotocol/python-sdk#3566 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
griptape-ai/griptape#2353 ·