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
For code reviews, follow guidelines, tests, and validate instructions. For creating or updating pull requests or branches, follow the steps instructions.
7
+
For code reviewsand for creating or updating pull requests, follow the Guidelines, Tests, and Validate sections below.
8
8
9
9
## Guidelines
10
10
11
+
- Before you make a new branch, make sure you have the latest changes by running `git checkout main && git pull`.
11
12
- If available, use ripgrep (`rg`) instead of `grep`.
12
13
- When using gh cli in double-quoted strings, escape backticks to prevent bash command substitution. In single-quoted strings, backticks do not need escaping.
13
14
- All scripts should be listed in `package.json` and use `tsx`.
@@ -17,6 +18,9 @@ For code reviews, follow guidelines, tests, and validate instructions. For creat
17
18
- We use absolute imports, relative to the `src` directory, using the `@` symbol. For example, `getRedirect` which lives in `src/redirects/lib/get-redirect.ts` can be imported with `import getRedirect from '@/redirects/lib/get-redirect'`. The same rule applies for TypeScript (`.ts`) imports, e.g. `import type { GeneralSearchHit } from '@/search/types'`
18
19
- For updates to the content linter, read important information in `src/content-linter/README.md`.
19
20
- Do not use git force push, and avoid git rebase.
21
+
- When reading issues and pull requests, read all comments as well.
22
+
- When you are updating an existing pull request, after you commit and push, _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why.
23
+
- When running in agentic mode, offer the human the option to wait for and review CI checks and automatic Copilot code review comments.
20
24
21
25
## Tests
22
26
@@ -79,30 +83,6 @@ Run the following commands to validate your changes:
79
83
-`npm run prettier`
80
84
-`npm run lint`: you can include `-- --fix`
81
85
82
-
## Steps
83
-
84
-
0. Ask the human if they would like you to follow these steps.
85
-
1. If this is new work, make sure you have the latest changes by running `git checkout main && git pull`. If this is existing work, update the branch you are working on with the head branch -- usually `main`.
86
-
2. If the human provides a GitHub issue, use MCP or gh cli to read the issue and all comments.
87
-
3. Begin by evaluating impact, effort, and estimate non-test lines of code that will change. Ask for more context and examples if needed.
88
-
4. If you are running in agentic mode, _stop_ at this point and request approval from the human.
89
-
5. If you need to add or change tests, work on tests before implementing.
90
-
6. Implement the changes needed. If you are running in agentic mode, _stop_ and ask questions at decision points. Please list the options, pros and cons for each decision needed.
91
-
7. Validate your changes before making any commits. See "Validate".
92
-
8. Validate that any new or changed tests pass. See "Tests".
93
-
9. Validate that these changes meet our guidelines. See "Guidelines".
94
-
10. If you are running in agentic mode, _stop_ at this point and request review before continuing. Suggest how the human should review the changes.
95
-
11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are GitHub Copilot and what changes you made and why.
96
-
12. If this is new work and no pull request exists yet, make a pull request:
97
-
- label "llm-generated"
98
-
- draft mode
99
-
- include "fixes owner/repo#issue" or "towards owner/repo#issue" as appropriate
100
-
13. If you are in agentic mode, offer to wait for CI to run and check that it passes. If the human agrees, verify in CI: `sleep 240 && gh pr checks $number`. Address all failures, don't assume they're flakes.
101
-
14. If you are in agentic mode, offer to do any or all of:
102
-
- mark the pull request as ready,
103
-
- assign the issue to the human if it is not already assigned,
104
-
-_concisely_ comment on the issue explaining the change, indicating you are GitHub Copilot.
105
-
106
86
## Logger
107
87
108
88
Use `createLogger` from `@/observability/logger` instead of `console.log` in server-side code.
Copy file name to clipboardExpand all lines: .github/instructions/content.instructions.md
+44Lines changed: 44 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,3 +92,47 @@ Examples:
92
92
* ❌ Incorrect: "The cat – which sat on a branch – smiled with a broad grin." (en dash with spaces)
93
93
* ❌ Incorrect: "The cat-which sat on a branch-smiled with a broad grin." (hyphen without spaces)
94
94
* ❌ Incorrect: "The cat - which sat on a branch - smiled with a broad grin." (hyphen with spaces)
95
+
96
+
## Versioning
97
+
98
+
Follow one of these sets of instructions, depending on how articles are versioned in the frontmatter. Articles may be versioned for FPT and GHEC, for GHES only, or for all three. Articles may also be versioned using feature-based versioning defined in `data/features`. Feature-based versioning allows centralized control of when content appears for specific GHES releases.
99
+
100
+
### FPT/GHEC-only articles
101
+
102
+
All articles that are ONLY for FPT and GHEC should be versioned for these versions in the frontmatter.
103
+
104
+
For such content, DO NOT use in-article Liquid versioning such as `{% ifversion fpt %}`, `{% ifversion ghec %}`, and `{% ifversion fpt or ghec %}`.
105
+
106
+
### GHES-only articles
107
+
108
+
All articles that are ONLY for GitHub Enterprise Server (GHES) should be versioned in the frontmatter using feature-based versioning defined in `data/features/`.
109
+
110
+
### FPT, GHEC, GHES articles
111
+
112
+
All articles that are versioned for all of FPT, GHEC, and GHES in the frontmatter MAY require certain blocks of content to be versioned using in-article Liquid versioning. Before recommending this, check if this is really the case.
113
+
114
+
#### Check in-article versioning is required
115
+
116
+
Before resorting to in-article versioning, first consider whether the content is actually different across versions. Often procedures can be simplified to work at both levels.
117
+
118
+
Use these strategies instead of `{% ifversion %}`, depending on the level of content:
119
+
120
+
**At the article level:**
121
+
122
+
* When the feature is only available in certain products, use the "Who can use this feature?" box to convey that the content of the article applies only to specific products
123
+
* When an article only exists because the functionality is only available in older GHES releases (and not on {% data variables.product.prodname_dotcom_the_website %} or newer GHES releases), just remove that article
124
+
125
+
**At the heading level:**
126
+
127
+
* Use prose similar to "Who can use this feature?" to convey that the content of a section applies only to specific products
128
+
129
+
**At the paragraph or sentence level:**
130
+
131
+
* If you're briefly introducing a feature and then linking to an article, there's no need to specify versioning. Let readers learn availability when they follow the link, via the "Who can use this feature?" box
132
+
* When necessary, start sentences with "With {% data variables.product.prodname_ghe_cloud %}...", "On {% data variables.product.prodname_dotcom_the_website %}...", etc.
133
+
* End list items with "({% data variables.product.prodname_ghe_cloud %} only)", "({% data variables.product.prodname_dotcom_the_website %} only)", etc.
134
+
* Specify if the feature is not available for GHES with "NAME-OF-FEATURE is not available for {% data variables.product.prodname_ghe_server %}", "... (not available in {% data variables.product.prodname_ghe_server %})", etc.
135
+
136
+
#### If in-article versioning is required
137
+
138
+
In-article versioning is required if a block of content in an article is definitely ONLY relevant for GHES, but the article itself is otherwise versioned in the frontmatter for all of FPT, GHEC, and GHES. In this situation, use feature-based versioning (FBV) wherever possible, using `{% ifversion FBV %}` blocks, where FBV is defined in `data/features/`. If it's not possible to use FBV, use {% ifversion ghes %} blocks, which will version the content block for all versions of GHES.
Copied to this repo by the [$GITHUB_WORKFLOW workflow run]($GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID)." --repo github/docs-content --label "workflow-generated")"
Copy file name to clipboardExpand all lines: .github/workflows/generate-code-scanning-query-lists.yml
+3-1Lines changed: 3 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -259,4 +259,6 @@ jobs:
259
259
No action is required from the first responder for the Docs content team. This PR is automatically added to the Docs content review board. Any writer can review this by checking that the PR looks sensible. If CI does not pass or other problems arise, contact #docs-engineering on slack.
260
260
261
261
262
-
When the DRI for the CodeQL CLI release is ready to publish, they will ask us to merge this PR in #docs-content.'
262
+
When the DRI for the CodeQL CLI release is ready to publish, they will ask us to merge this PR in #docs-content.
263
+
264
+
_Generated by the [Generate code scanning query lists](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}) workflow run._'
0 commit comments