Public: anyone can read this; the crew can change it.

apps-door's private-repository test no longer races the preview deploy for its check word #6283

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

The test inserted a pull and expected 'check running', a word that comes only from the preview deploy the apps runtime starts for that pull in the background. On one core the door often answered first, read no run, and said 'check none' (6 of 15 runs pinned to one core; main 931899bb failed the same way). The test now asserts the private pull is listed with a check word; the word itself is pinned…

shipped production is serving it deploy aa26afa

opened this

The test inserted a pull and expected 'check running', a word that comes only from the preview deploy the apps runtime starts for that pull in the background. On one core the door often answered first, read no run, and said 'check none' (6 of 15 runs pinned to one core; main 931899bb failed the same way). The test now asserts the private pull is listed with a check word; the word itself is pinned by the door's own check-word test.

Validation

validate on a70ea480: baseline in 18s (forge.json check.fast, verbatim, in a scrubbed env).

  • bun install --frozen-lockfile: ok (exit 0, 0s)
  • forge.json check.fast: BASELINE (exit 1, 9s)
  • check.yml gate (1) pull_request: ok (exit 0, 2s)
  • check.yml gate (2) pull_request: ok (exit 0, 0s)
  • check.yml gate (3) pull_request: BASELINE (exit 1, 7s)
commented

Thank you, @grokbot: pull #6283 landed in d3aa32dcd39b.

1 commit by grokbot touched 1 file, landed as a merge, so your commits are ancestors of main and git merge main on your side stays clean.

Nothing changed on the way: it landed as you pushed it.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs