You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a23dccf
Browse filesBrowse the repository at this point in the historyBrowse files
integration-test-submitqueue-validator: ## Run the GitHub validator extension test (needs SQ_GITHUB_TOKEN and SQ_GITHUB_TEST_REPO=owner/repo, else skips)
Copy file name to clipboardExpand all lines: doc/howto/TESTING.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -94,7 +94,7 @@ make build-all-linux # Build Linux binaries for the local docker-
94
94
95
95
### Live GitHub Tests
96
96
97
-
Two suites land real pull requests on github.com: `TestGitHubLandE2E` (in `make e2e-test`)and the Runway GitHub merger extension test (`make integration-test-runway-merger`). They run only when `SQ_GITHUB_TOKEN` and `SQ_GITHUB_TEST_REPO=owner/repo` are set, and skip otherwise, so every other run is unaffected. The token needs write access to the test repository; everything the tests open is named under `sq-it/` and removed afterwards, while what they merge stays on its default branch.
97
+
Three suites open real pull requests on github.com: `TestGitHubLandE2E` (in `make e2e-test`), which lands them through the whole stack with the GitHub change provider, validator and merger; the Runway GitHub merger extension test (`make integration-test-runway-merger`); and the GitHub validator extension test (`make integration-test-submitqueue-validator`). They run only when `SQ_GITHUB_TOKEN` and `SQ_GITHUB_TEST_REPO=owner/repo` are set, and skip otherwise, so every other run is unaffected. The token needs write access to the test repository; everything the tests open is named under `sq-it/` and removed afterwards, while what they merge stays on its default branch.
98
98
99
99
```bash
100
100
SQ_GITHUB_TOKEN=$(gh auth token) SQ_GITHUB_TEST_REPO=<owner>/<repo> make e2e-test
@@ -107,7 +107,7 @@ CI takes the repository from the `SQ_GITHUB_TEST_REPO` repository variable and t
107
107
Any contributor can run these suites against a repository of their own:
108
108
109
109
1. Create a repository on github.com with a default branch (an initial commit is enough). It must allow squash and rebase merges, and its default branch must not require reviews or status checks, since the tests merge directly.
110
-
2. Create a token that can write to it: a fine-grained token limited to that repository with read and write access to contents, pull requests and issues, or simply `gh auth token`.
110
+
2. Create a token that can write to it: a fine-grained token limited to that repository with read and write access to contents, pull requests and issues and read access to checks and commit statuses, or simply `gh auth token`.
111
111
3. Run locally with `SQ_GITHUB_TOKEN` and `SQ_GITHUB_TEST_REPO` set, as above.
112
112
4. For CI in your fork, set the `SQ_GITHUB_TEST_REPO` repository variable and the `SQ_TEST_REPO_TOKEN` repository secret in the fork's Actions settings. Runs in the fork then exercise your test repository.
Copy file name to clipboardExpand all lines: doc/rfc/stovepipe/project-status-api.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ The request and response fields have the following API-level meaning. The publis
17
17
|`queue`| Yes | Identifies the queue in which to find the validation request. |
18
18
|`request_id`| ID lookup | Canonical positive decimal request ID returned by `Ingest`. |
19
19
|`change_uri`| URI lookup | Identifies the exact commit URI under validation. |
20
-
|`projects`|Yes| Consumer-defined project IDs whose results are requested. At least one ID is required. |
20
+
|`projects`|No| Consumer-defined project IDs whose results are requested. Omitted or empty returns all recorded project results. |
21
21
|`page_size`| No | Limits one page of results for the requested projects. |
22
22
|`page_token`| No | Continues a previous page of results for the requested projects. |
23
23
@@ -29,7 +29,7 @@ The request and response fields have the following API-level meaning. The publis
29
29
|`updated_at_ms`| Records, in Unix milliseconds, the newest durable lifecycle or result record represented by the response. |
30
30
|`repository_breakage_degree`| Returns the whole-repository result when it is durably recorded. |
31
31
|`project_results_complete`| Indicates whether the implementation has durably finished producing results for the supplied project IDs. |
32
-
|`projects`| Returns recorded results for requested project IDs. |
32
+
|`projects`| Returns recorded results for requested project IDs, or all recorded project results when none are supplied. |
33
33
|`next_page_token`| Continues requested-project result pagination when another page exists. |
34
34
35
35
`request_state` is a stable public lifecycle vocabulary: `accepted`, `processing`, `succeeded`, `failed`, `cancelled`, or `superseded`. Clients must tolerate a future value. A terminal request state does not by itself mean that project results are complete.
@@ -56,25 +56,27 @@ Both lookups are queue-scoped and use the same durable request summary and valid
56
56
57
57
The request-URI mapping admits one request per `(queue, change_uri)`, so the endpoint returns one authoritative request. Revalidation support must introduce an explicit authoritative-request rule; it must not silently change this lookup's meaning.
58
58
59
-
Queue, URI, request ID, and project ID comparisons are byte-exact and are limited to 255 bytes. An empty queue, lookup selector, project list, or project ID is invalid. A request cannot contain duplicate project IDs. `page_size=0` selects the default of 50; the maximum is 200. Request IDs use the same canonical positive decimal format as `Ingest` and request-history lookups. Page tokens are opaque and bound to the selected request and requested project list; either endpoint can continue a page for the same queue, request, and projects.
59
+
Queue, URI, request ID, and project ID comparisons are byte-exact and are limited to 255 bytes. An empty queue, lookup selector, or individual project ID is invalid. A request cannot contain duplicate project IDs. `page_size=0` selects the default of 50; the maximum is 200. Request IDs use the same canonical positive decimal format as `Ingest` and request-history lookups. Page tokens are opaque and bound to the selected request and requested project list; either endpoint can continue a page for the same queue, request, and projects.
60
60
61
61
## Project Results and Pagination
62
62
63
-
The caller supplies the project IDs for which it wants recorded results. The API does not define project discovery, validation selection, or attribution. A project absent from the response has no universal meaning and consumers must not infer that it is green.
63
+
The caller may supply the project IDs for which it wants recorded results. The API does not define project discovery, validation selection, or attribution. A project absent from the response has no universal meaning and consumers must not infer that it is green.
64
64
65
-
The response includes only results for the supplied project IDs, in the supplied order, and paginates that list. An implementation may record results for every requested project, only requested projects with a non-green result, or another documented subset.
65
+
When project IDs are supplied, the response includes only results for those IDs, in the supplied order, and paginates that list. An implementation may record results for every requested project, only requested projects with a non-green result, or another documented subset.
66
+
67
+
With no project IDs supplied, the response lists all recorded project results in project-ID order, excluding the repository fact. Results are a live view; restart pagination to discover facts recorded behind the cursor.
66
68
67
69
Each project result is an immutable validation fact keyed by queue, commit URI, and project ID. A result must identify the selected request. `project_results_complete` is false until the implementation has durably finished producing results for the supplied project IDs; a completed empty set is valid.
68
70
69
71
Callers use `project_results_complete`, rather than the presence or absence of an individual project result, to determine whether the implementation has finished producing results for the requested projects. `next_page_token` is empty only on the final page. A terminal lifecycle notification is emitted only after the repository result and any applicable project completion record are durable. If notification delivery fails, consumers can recover the same result through either endpoint.
70
72
71
73
## Implementation
72
74
73
-
Both endpoints return durable lifecycle summaries, the whole-repository fact when present, and any recorded facts for requested projects in paginated request order. `project_results_complete` remains false until a durable completion projection is available. Missing facts are omitted; an explicitly recorded zero degree remains present. `updated_at_ms` is the maximum timestamp of the summary and the facts represented on the page.
75
+
Both endpoints return durable lifecycle summaries, the whole-repository fact when present, and recorded facts for requested projects in paginated request order, or all recorded project results in project-ID order when none are requested. `project_results_complete` remains false until a durable completion projection is available. Missing facts are omitted; an explicitly recorded zero degree remains present. `updated_at_ms` is the maximum timestamp of the summary and the facts represented on the page.
74
76
75
77
## Errors and Authorization
76
78
77
-
- Invalid selectors, an empty project list, an invalid project ID, duplicate project IDs, or malformed page tokens are user errors.
79
+
- Invalid selectors, an invalid project ID, duplicate project IDs, or malformed page tokens are user errors.
78
80
- An unknown queue-scoped request ID or commit URI is not found.
79
81
- A request-URI mapping whose summary is not visible is retryable.
80
82
- A selector and summary that disagree, a result belonging to another request, or a completion record with a missing project result is an internal consistency error.
Copy file name to clipboardExpand all lines: service/submitqueue/demo/provider/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ Each directory here is one **provider** — a code-hosting system SubmitQueue la
4
4
5
5
| File | Selects |
6
6
|---|---|
7
-
|`profiles.yaml`| the change provider, build runner, conflict analyzer, scorer and build budget each queue resolves to (read by the orchestrator) |
7
+
|`profiles.yaml`| the change provider, validator, build runner, conflict analyzer, scorer and build budget each queue resolves to (read by the orchestrator) |
8
8
|`merge.yaml`| the merge target each queue lands on (read by Runway) |
9
9
10
10
Neither holds a secret. Each integration names the *environment variable* carrying its credential, so these files stay committable and rotating a token needs no edit.
0 commit comments