Skip to main content
A named check is one pass or fail recorded on a work item under a name you choose, such as ui-review or e2e. Record one from CI or a terminal with outerlayer emit <name>. A check counts only once a validator in .outerlayer/validators/ declares its name. Until then it is stored, but shown nowhere and blocks nothing. See Checks that run in CI. Say what is wrong in one sentence:
Read the sentence from a file, or from standard input with -:
Record a pass once the work is right. --result defaults to pass:
A check with a run to point at carries its URL instead of a sentence:

​
Rules

  • --item is always required. A check is recorded on the work item, not on one pull request, so it holds across every pull request the item has.
  • A fail needs a link or a sentence. A pass needs neither.
  • A session records checks on its own item. Inside a recorded session, a check on the item that session was launched for is stored as the session’s.
  • Only a person can record over a person’s fail. A session or a machine key is refused.
  • Your key decides who recorded the check, not the request. A key bound to you records as you. A key with no person behind it, such as one for CI, records as a machine. Inside a recorded session the session records it, even with your own key.
  • Every row says who recorded it. The Checks tab and the pull request comment name CI, a machine key, the person, the build session, or the host that ran it. A review of the whole item is not a named check. Record it on the item page, or with outerlayer work comment. See Review and merge. The Quality chart on the Metrics → Overview dashboard reads reviews only, never named checks.

​
Permissions

The caller needs Emit evidence. See API keys. A browser outerlayer login holds Emit evidence only when your role can create factory keys. The owner, admin and write roles can. Otherwise, use a factory key bound to you.