Update Managing Rulesets in regards to status checks
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 74/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github-actions
- Domain
- documentation
Research direction
Start with the “Require status checks to pass before merging” section in the linked Managing Rulesets article and compare it with the existing status checks documentation. Update the documentation to explain that GitHub Actions jobs can be status checks, including how a workflow job’s name key is used in a ruleset and a brief example or step-by-step guide.
Written by the indexing model from the issue text.
Description
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?
What part(s) of the article would you like to see updated?
The Require Status Checks Before Merging section should more clearly mention that Github Actions (through their jobs) can be configured as status checks. The Github documentation page for status checks does mention this, however on the Managing Rulesets page it does not. More importantly, there should be instructions on how to add a workflow job as a status check on this page--I was unable to find how to do this in any official documentation available. A workflow's job-level name key can be used to add a status check in a ruleset. This should either be explained in full on the Managing Rulesets page, and if not there, then it should either be its own page or perhaps as part of the status check documentation. Providing users a brief example/step-by-step guide is not only helpful, but makes this process more transparent AND highly reputable since it would be in official documentation itself.
Additional information
Feel free to message me with any questions or feedback. Thank you!
- Dominant language
- TypeScript
- Stars
- 20.9k
- Forks
- 68.8k
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 103
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/docs
-
builder persona content
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
localization
Difficulty 2/5 1-2 days Newbie friendliness 72/100
-
builder persona
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
content localization
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
content localization
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Similar issues
-
S: triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
snapshot-labs/stamp#666 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GauravKarakoti/SecureFlow#1070 · 1 comment ·
-
feature:Languages/Translations good first issue ready Web
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
digitalfabrik/integreat-app#4394 ·