Forgejo and Gitea: why the required checks do not pass
When the protection rule of the target branch has Enable status check on, Forgejo and Gitea merge a pull request only when the required checks on its head commit pass. Until then the merge box says Some required checks were not successful. or Some required checks are missing., and a merge through the API answers 405 Not all required status checks successful (see why the merge was refused). From the source of both (MergeRequiredContextsCommitStatus in services/pull/commit_status.go, and the merge box of Forgejo in templates/repo/issue/view_content/pull.tmpl; Gitea has the same messages), this is how the server decides.
The two messages
Some required checks were not successful.: a required check ended infailureorerror. A job of Forgejo Actions or Gitea Actions that failed or was cancelled reportsfailure.Some required checks are missing.: anything else that is not a pass. That is a pattern that no status on the head commit matches yet (the list of checks shows it with a yellow dot and the label Required), a check that is stillpending(a job that is waiting, blocked or running), and in Forgejo also awarning.
A repository administrator sees As an administrator, you may still merge this pull request. and may merge anyway, unless the rule applies to administrators as well.
How the server reads the required checks
- Only the latest status of each name counts, and only on the head commit of the pull request. A check that passed on an older commit does not count after a push.
- Each pattern must match at least one status. A pattern that matches none keeps the merge waiting, even when every other check passed. Of the statuses that one pattern matches, the worst one counts.
- A pattern is a glob (the gobwas/glob library, without separators):
*and**match any text, slashes included;?matches one character;[abc],[a-z],[!abc]and[!a-z]match one character (a range or a list, not both in one bracket);{lint,test}matches any of the alternatives; and\takes the next character as it is. Soci / *matches every job of the workflow named ci. The settings page refuses a pattern it cannot read (Invalid status check pattern). A rule saved before the patterns were globs can still hold one, and the merge then leaves that pattern out. - No patterns: every status on the commit counts, and there must be at least one. The settings page says so:
If no contexts are matched, the last commit must be successful regardless of context.
Skipped and warning
skippedpasses. Forgejo Actions reports a skipped job asskippedfrom Forgejo 16, and assuccessbefore it; Gitea has the state from 1.25. One exception in Forgejo: with no patterns, a commit where every status is skipped does not pass. Gitea lets it through.warningdoes not pass in Forgejo, nor in Gitea 1.26 and later, which counts it as a failure. Gitea 1.25 let a warning through.
The names that Actions gives its checks
Forgejo Actions and Gitea Actions report each job as WORKFLOW / JOB (EVENT): the name of the workflow, the name of the job, and the event that started the run, for example ci / test (pull_request). Gitea uses the file name of the workflow (such as ci.yml) when the workflow has no name:. Three things follow from it:
- The same job started by a push and by a pull request is two checks,
ci / test (push)andci / test (pull_request). A pattern that names the event matches only one of them; end it with(*)to take either. - Renaming the workflow or the job renames the check. The old pattern then matches nothing, and the merge waits for a check that will never come.
- A workflow that does not run for the pull request (its
on:has nopull_request, or itspathsfilter leaves it out) reports nothing, so a pattern for it stays missing.
Gitea 1.27 and later add required workflows that the owner or the instance administrator sets for many repositories. Their checks are named SOURCE: WORKFLOW / JOB (EVENT), where SOURCE is the repository the workflow comes from, and they block a merge into any branch that has a protection rule, even when the rule has its own status check off. The branch API does not list them in status_check_contexts.
What to do
- Missing: compare the names in the list of checks of the pull request with the patterns of the rule (repository settings, Branches). The rule page lists the checks that reported in the last week and marks the ones a pattern matches (Matched). Fix the pattern, or make the workflow run for pull requests.
- Not successful: open Details next to the check, fix the job, and push or run it again.
- Pending for long: a job of Actions that says
Waiting to runorBlocked by required conditionsnext to the check has not started yet. Open the run through Details to see what it waits for. - A warning in Forgejo: the merge waits until the system that reported it reports success.
To read what the server reads:
curl -H "Authorization: token your-token" https://codeberg.org/api/v1/repos/OWNER/REPO/commits/HEAD-SHA/status curl -H "Authorization: token your-token" https://codeberg.org/api/v1/repos/OWNER/REPO/branches/main
The first gives the latest status of each name (statuses, each with its context and status), the second the rule as it applies to the branch (enable_status_check and status_check_contexts). Use your own server instead of codeberg.org. The settings themselves are described in the Forgejo documentation and the Gitea documentation.
Forgejo and Gitea pull requests in IntelliJ IDEA
Pull Request Inbox for Forgejo and Gitea, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows the required checks as one of the merge checks of a pull request, from the rule of the target branch (enable_status_check and status_check_contexts) and the statuses on the head commit, and lists each status with a link to its page. It reads them as the server does: a skipped check passes and a warning does not, the patterns are globs ({a,b}, [abc], [!a-z]), and with no patterns it follows Forgejo or Gitea on a commit where every status is skipped; the server has the final say. Before version 1.0.22, it counted a skipped check as not passed and read only * and ? in the patterns. It does not see the required workflows of Gitea 1.27, which the API does not list. Reading is free; approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).
Forgejo, Gitea and Codeberg are names of their respective owners; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by the Forgejo project, Codeberg e.V., the Gitea project or JetBrains.
More: Forgejo and Gitea merge refused (405, 409) · Forgejo and Gitea merge when checks succeed refused (405, 409, 500) · Forgejo and Gitea review refused (422) · Forgejo and Gitea branch update refused (403, 409, 422) · Forgejo and Gitea 404: missing, private or renamed · 401 "token is required" and unknown tokens · "token does not have at least one of required scope(s)" · Forgejo and Gitea pull request not created (409, 422, 403) · Forgejo and Gitea comment refused (403, 422, 400) · Forgejo and Gitea search refused (400, 422) · Forgejo and Gitea pull request files (pages of 50, changed_files) · Forgejo and Gitea pull request plugins for IntelliJ IDEA, compared · 日本語