What Happens When PR Checks Find Errors or Warnings
You have opened your pull request. Now what? This page walks through exactly what happens next: which checks run, where their results appear, which ones can hold up a merge, and how to read and fix each message with concrete examples. If you have not yet met the individual checks, the Overview introduces them one by one.
What happens the moment you open or update a PR
As soon as you open a pull request against dev (or main), or push a new commit to it, GitHub starts the relevant checks. Two things are worth knowing from the start:
- The checks are path-filtered. Each one only runs when the files it cares about actually changed. Edit a single Markdown page and you will not trigger the Draw.io check; add an image and the spelling check stays quiet. You only ever see feedback that is relevant to what you touched.
- Results arrive within a few minutes. The checks run in parallel. Most finish in well under five minutes, and each one reports as soon as it is done, so you do not have to wait for all of them before fixing the first problem.
Contributing through the no-code Quick Start editor? The same checks run on the pull request it opens for you. Everything on this page applies in exactly the same way; you just read the results on GitHub.
Three places results show up
The checks never leave you searching. Findings land in one (or more) of three surfaces, and every check also writes an expandable job summary under its entry on the Checks tab.
| Where you look | What you find there | Checks that report here |
|---|---|---|
| Files changed tab: inline annotations pinned to the exact line | A speech-bubble comment next to the offending word, link, or front matter field | Typos, Spelling, Internal Links, SEO Front Matter, Front Matter Properties, Reference Architecture IDs, Draw.io Files, Orphan Files |
| Checks tab: one entry per check | Status (tick / cross / note), full run log, and a job summary | Grammar (and every other check also writes a job summary here) |
| One sticky PR comment titled 🔎 Content check results | Findings grouped by check, rebuilt on every run | Internal Links, SEO Front Matter, Front Matter Properties, Reference Architecture IDs, Draw.io Files, Orphan Files, External Links |
A few deliberate details about the sticky comment:
- Typos and Spelling are not in it. They annotate inline on the Files changed tab only, right next to the word in question, which is the fastest place to fix them.
- Grammar is not in it either. Grammar suggestions appear on the Checks tab.
- It is idempotent. The comment rebuilds its entire body every time a check finishes, so it always reflects your latest commit. Look for the footer line noting the commit it was updated for.
- It works on fork pull requests. The comment is assembled in the base repository's context and never checks out your PR's code, so it can post results even for contributions from a fork, without ever running your changes with a writable token.
- It shows blocking errors only. A non-blocking warning (for example an SEO length outside the recommended range, or an asset referenced only outside its RA folder) appears inline on the Files changed tab and in the job summary, not in this comment. A check that reports only warnings still shows as a pass here.
If a check does not appear in the sticky comment at all, that usually means its paths did not match your changes, so it never ran. That is normal and expected, not a failure.
Blocking vs non-blocking
Not every finding stops a merge. Some are hard gates; others are friendly suggestions. Here is the split.
| Blocking: fails the check and holds the merge | Non-blocking: a warning you should weigh, but which never fails the build |
|---|---|
| Typos: any typo in changed Markdown | Grammar: always advisory, by design |
| Spelling: any unknown word | SEO Front Matter: a value merely outside the recommended range |
| SEO Front Matter: a value past the hard bounds | Orphan Files: an asset referenced only outside its own RA directory |
| Front Matter Properties: any missing/non-conforming field | |
Reference Architecture IDs: bad id or slug | |
| Internal Links: any SAP-internal-only host | |
| External Links: any broken external URL | |
| Draw.io Files: oversized file or external image reference | |
| Orphan Files: an asset referenced nowhere |
The SEO and Orphan Files checks each sit on both sides of the line. SEO fails only when a title or description blows past the hard minimum/maximum; a value that is merely shorter or longer than the ideal range is a warning. Orphan Files fails only when an asset is referenced nowhere; an asset referenced only outside its RA folder is a warning (it might legitimately be shared).
A pull request with nine problems
Imagine a single PR that adds a new reference architecture and manages to trip almost everything at once. Here is each problem, the message you would see, and the one-line fix. (All values below are illustrative.)
1. A misspelling: "integreation"
You wrote integreation instead of integration.
docs/ref-arch/RA1234/readme.md:12:5 - Unknown word (integreation)
An inline annotation lands on that word on the Files changed tab, titled Spelling (and Typos flags common slips like this too). Fix: correct the spelling. See Spelling and Typos.
2. A valid new product name flagged by cspell
Your architecture legitimately mentions a brand-new SAP product, but cspell has never heard of it, so it reports it as an unknown word, the same shape of message as above.
Fix: this is not a typo, so do not change the text. Add the term to the project dictionary at .cspell/sap.txt (one word per line) and commit that too. The next run will accept it. See Custom Dictionaries.
The custom dictionaries are how the project teaches cspell every SAP-specific name: products, acronyms, service names. When a correct term is flagged, the fix is almost always "add it to the dictionary," never "reword the sentence." The Custom Dictionaries page explains which file to use.
3. A 72-character title: SEO "way too long"
Your front matter title runs to 72 characters. The hard maximum is 65.
docs/ref-arch/RA1234/readme.md:4: title is way too long (72 characters, hard maximum 65; recommended 40-60 characters).
This is a blocking error (past the hard bound). Fix: tighten the title into the recommended 40–60 character range. Had it been, say, 63 characters, you would have seen a non-blocking warning instead. See SEO Front Matter.
4. Missing contributors / stale date
You forgot to add yourself to contributors, and the last_update.date is from last month.
docs/ref-arch/RA1234/readme.md: contributors is missing or does not include the PR author.
docs/ref-arch/RA1234/readme.md: last_update.date is older than 7 days before today.
Both are blocking. Fix: add your GitHub login to contributors, set last_update.author to your login, and bump last_update.date to today. See Front Matter Properties and the general front matter guide.
5. slug not matching id: "SLUG MISMATCH"
Your readme has id: ra1234 but slug: /ref-arch/ra9999.
SLUG MISMATCH slug "/ref-arch/ra9999" != "/ref-arch/ra1234" -> docs/ref-arch/RA1234/readme.md
The id must be exactly six lowercase letters/digits, and the slug must be /ref-arch/<id>. Fix: make the slug match the id (/ref-arch/ra1234). See Reference Architecture IDs.
6. A link to an SAP-internal host
You linked to an internal wiki that external visitors cannot reach.
See the [internal design note](https://wiki.example-internal.invalid/display/ARCH/notes).
docs/ref-arch/RA1234/readme.md:40: Internal-only SAP link (breaks for external visitors): https://wiki.example-internal.invalid/...
(The .invalid host above is a stand-in. On a real PR this would be a host ending in one of the internal suffixes below. We never put a real internal host in content, including in examples.) The check flags any host matching *.tools.sap, *.int.sap, *.sap.corp, or sap.sharepoint.com. Fix: link to a public source instead, or remove the link. See Internal Links.
7. A dead external URL (404)
One of your external links returns 404 Not Found. The check reports it in the job summary and in the sticky comment (not as an inline annotation, because broken links are often network-dependent and not tied to a changed line).
✗ https://example.com/this-page-moved | 404 Not Found
Fix: update the URL or point it at a working page. See External Links.
8. A 1.4 MB .drawio diagram
You committed a diagram source file of about 1.4 MB. The limit is 1024 KB.
❌ docs/ref-arch/RA1234/diagram.drawio is too large (1434 KB). Maximum allowed size is 1024 KB.
Fix: slim the diagram down: embedded raster images are the usual culprit. (The same check also fails on external image references inside a .drawio; images must be embedded, not linked.) See Draw.io Files and the diagramming guide.
9. An added image that nothing references
You added architecture-overview.png but no page links to it.
❌ docs/ref-arch/RA1234/architecture-overview.png: Asset is not referenced in any Markdown file
This is blocking. Fix: reference the image from your Markdown, or remove it if it is not needed. If the same image is instead referenced only from another RA's folder, you would get a non-blocking ⚠️ warning ("referenced only outside its RA directory") rather than an error. See Orphan Files.
Fixing and re-running
There is nothing special to trigger: push a new commit to the same branch and the checks re-run automatically on your updated files. The sticky 🔎 Content check results comment updates in place (it does not pile up new comments), so you always read the latest state in one spot.
Contributing from a fork? GitHub hands fork pull requests a read-only token, so the Grammar suggestions cannot be posted to the Checks tab; they appear in the Actions run log instead. The aggregated content-check comment still posts normally, because it is built in the base repository's context. Everything else behaves the same.
When everything is green
You can relax: the checks are there to help. They exist to help your content meet the house style in seconds, long before a human reviewer weighs in on the ideas. Because almost every check is path-scoped, you only ever see feedback about the files you actually changed. And when every check shows a green tick and the sticky comment reads all clean, your pull request is ready for human review.
For the big picture of how the whole system fits together, go back to the Overview. For the schedule-based and deployment workflows that run outside the PR flow, see Operational Workflows.