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 b8b56d4
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: src/automated-pipelines/README.md
+7-1Lines changed: 7 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ When creating a new pipeline, the source data that is being consumed may not hav
44
44
- Each pipeline typically requires a workflow to allow scheduling or manually running the pipeline. The workflow should be placed in the `.github/workflows` directory and named `sync-<pipeline-name>.ts`. Each workflow typically requires adding a manual run option and an input parameter to specify the source repo's branch to use.
45
45
- Each pipeline will need a `scripts` directory with (at minimum) a `scripts/sync.ts` file to run the pipeline.
46
46
- If the pipeline will contain structured data, you will need to add a `src/<pipeline-name>/data` directory. The files inside the `data` directory are typically organized by version (e.g., `src/webhooks/data/fpt/*`).
47
-
- Pipelines typically have tests specific to the pipeline that are placed in the `src/<pipeline-name>/tests` directory. There is no need to add tests that render the page because all autogenerated pages are tested in `src/automated-pipelines/tests/rendering.ts`.
47
+
- Pipelines typically have tests specific to the pipeline that are placed in the `src/<pipeline-name>/tests` directory. There is no need to add tests that render the page because all autogenerated pages are tested in `src/automated-pipelines/tests/rendering.ts`. Add the new `src/<pipeline-name>/**` path to the "Check for automated pipeline changes" step in `.github/workflows/test.yml` so PRs that change the pipeline render every page.
48
48
- If the pipeline uses a Next.js page component (e.g., `pages/**/*.tsx`), ensure there is a test that fails if that page component is moved or deleted.
49
49
50
50
## How to get help
@@ -175,6 +175,12 @@ All autogenerated pages tested in `src/automated-pipelines/tests/rendering.ts`:
175
175
- Links are valid
176
176
- Schema validation
177
177
178
+
The merge queue and PRs that change pipeline code or generated REST, GraphQL, or CodeQL CLI content render every autogenerated page. Other PRs and local runs render the pages in `PINNED_PAGES` in `src/automated-pipelines/tests/rendering.ts`, and every page for generators not listed there. To render every page locally, run:
179
+
180
+
```bash
181
+
AUTOGENERATED_RENDER_ALL=true npm test -- src/automated-pipelines/tests/rendering.ts
182
+
```
183
+
178
184
### Pipeline-specific tests
179
185
180
186
Each pipeline in `src/<pipeline-name>/tests/` should test:
| article-api | Article API endpoints (`/api/pagelist*`, `/api/article/body`, `/api/article/meta`) behind hovercards, llms.txt, and markdown delivery, plus the transformers for autogenerated pages. | Local server with fixture ROOT; no Elasticsearch/GitHub/external network. |**Medium**: reliable (no external infra) but covers real user/API surfaces. Contained, not site-wide. |
23
23
| assets | Dynamic image processing (PNG to WebP, resizing), static asset cache headers keyed by checksum URL, and archived enterprise asset proxying. | Local Express server; checked-in fixture images; external calls mocked with nock. |**Low**: deterministic, mocked network, clear failures. |
24
24
| audit-logs | Audit log event structure, field merging, allowlist filtering, GHES version handling, category notes, and page rendering. | Unit tests run standalone; the rendering test needs the local server (getDOM). |**Medium**: unit tests reliable; the rendering test can flake. Contained to the audit-log reference. |
25
-
| automated-pipelines | The pipeline that auto-generates/syncs content from external sources into markdown, plus autogenerated-page rendering and semver conversion. | Local server for the rendering check (retried HTTP calls); fixtures. |**Medium**: affects rendered docs; the rendering test's retried HTTP calls can flake. |
25
+
| automated-pipelines | The pipeline that auto-generates/syncs content from external sources into markdown, plus autogenerated-page rendering and semver conversion. | Local server for the rendering check (retried HTTP calls); fixtures. Renders all autogenerated pages in the merge queue and on PRs that change pipeline code or generated content, a pinned set per generator otherwise. |**Medium**: affects rendered docs; the rendering test's retried HTTP calls can flake. |
26
26
| color-schemes | Theme cookie parsing and mapping between CSS and Primer React color modes, including bad-input handling. | None (pure-function unit tests). |**Low**: pure-function unit tests, no flake. |
27
27
| content-linter | Markdown/YAML lint compliance: links, frontmatter schema, Liquid syntax, code annotations, alt text, versioning, and data references. | Changed files (DIFF_FILE) or full repo; markdownlint + custom rules. |**Low**: deterministic; reds = real content problems in the PR. |
28
28
| content-render | The Markdown/Liquid to HTML rendering pipeline: templates, parsing, syntax highlighting, link rewriting, and content transforms. | In-process rendering (unified + LiquidJS); cheerio; no external services. |**High**: affects every page; reds = real rendering bugs site-wide. |
0 commit comments