Repo sync

.github/instructions/all.instructions.md

@@ -0,0 +1,31 @@
+---
+applyTo: "**"
+---
+
+# Copilot instructions for docs.github.com
+
+This repository contains code to run the GitHub Docs site on docs.github.com, as well as the content that the site displays. We write the code in JavaScript and TypeScript, and we write the content primarily in Markdown.
+
+## Creating a pull request
+
+When you create a pull request:
+
+1. **Always** make the first line of the PR description the following (in italics):
+
+   `_Copilot Chat generated this pull request._`
+
+2. Optionally, you may include a collapsed section summarizing the prompt or discussion with Copilot Chat:
+
+   ```markdown
+   <details><summary>Prompt summary - submitted by @GITHUB-USER-ID</summary>
+
+   > [Prompt summary text here]
+
+   </details>
+   ```
+
+   This helps reviewers understand the context and intent behind the automated changes.
+
+3. Label with "llm-generated". 
+4. If an issue exists, include "fixes owner/repo#issue" or "towards owner/repo#issue" as appropriate. 
+5. Always _escape backticks_ when you use gh cli.

.github/instructions/code.instructions.md

@@ -0,0 +1,63 @@
+---
+applyTo: "src/**,.github/**,config/**,.devcontainer/**,**Dockerfile,package*.json"
+---
+
+# Copilot code instructions for docs.github.com
+
+For code reviews, follow guidelines, tests, and validate instructions. For creating or updating pull requests or branches, follow the steps instructions.
+
+## Guidelines
+
+- If available, use ripgrep (`rg`) instead of `grep`.
+- Make sure to always _escape backticks_ when using gh cli.
+- All scripts should be listed in `package.json` and use `tsx`.
+- Whenever you create or comment on an issue or pull request, indicate you are an LLM.
+- Be careful fetching full HTML pages off the internet. Prefer to use gh cli whenever possible for github.com. Limit the number of tokens when grabbing HTML.
+- Avoid pull requests with over 300 lines of code changed. When significantly larger, offer to split up into smaller pull requests if possible.
+- All new code should be written in TypeScript and not JavaScript.
+- We use absolute imports, relative to the `src` directory, using the `@` symbol. For example, `getRedirect` which lives in `src/redirects/lib/get-redirect.js` 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'`
+
+## Tests
+
+We use `vitest` to write unit tests. Tests live in their own files in the `tests` subdirectory of a source (src) directory, e.g. `src/search/tests/api-ai-search.ts`. For integration tests, we can use the mock server in `src/tests/mocks/start-mock-server.ts` to mock external requests. For UI rendering tests, we use `playwright` and write tests in `src/fixtures/tests/playwright-rendering.spec.ts`
+
+- `npm run test`: For all unit tests
+  - You can pass specific paths, e.g. `npm run test -- src/search/tests/ai-search-proxy`
+  - You can add `--silent=false` to include `console.log` debugging.
+- `npm run build && npm run playwright-test -- playwright-rendering`: You need to build for changes outside of the test to be picked up. We use playwright for all rendering and end-to-end tests
+  - You can add `--ui` to keep open `localhost:4000` which can be viewed in a simple browser for debugging UI state.
+- `npm run dev` to start the development server on `localhost:4000`.
+- `ROOT=src/fixtures/fixtures TRANSLATIONS_FIXTURE_ROOT=src/fixtures/fixtures/translations vitest src/fixtures/tests` for tests that involve fixtures.
+
+## Validate
+
+Run the following commands to validate your changes:
+
+- `npm run tsc`
+- `npm run build`
+- `npm run prettier`
+- `npm run lint`: you can include `-- --fix`
+
+## Steps
+
+0. Ask the human if they would like you to follow these steps.
+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`.
+2. If the human provides a GitHub issue, use gh cli to read the issue and all comments.
+3. Begin by evaluating impact, effort, and estimate non-test lines of code that will change. Ask for more context and examples if needed.
+4. If you are running in agentic mode, _stop_ at this point and request approval from the human.
+5. If you need to add or change tests, work on tests before implementing.
+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.
+7. Validate your changes before making any commits. See "Validate".
+8. Validate that any new or changed tests pass. See "Tests".
+9. Validate that these changes meet our guidelines. See "Guidelines".
+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.
+11. If a branch and pull request already exist, commit and push, then _concisely_ comment on the pull request that you are an LLM and what changes you made and why. 
+12. If this is new work and no pull request exists yet, make a pull request:
+    - label "llm-generated"
+    - draft mode
+    - include "fixes owner/repo#issue" or "towards owner/repo#issue" as appropriate
+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.
+14. If you are in agentic mode, offer to do any or all of:
+    - mark the pull request as ready,
+    - assign the issue to the human if it is not already assigned, 
+    - _concisely_ comment on the issue explaining the change, indicating you are an LLM.

.github/copilot-instructions.md → .github/instructions/content.instructions.md

@@ -1,56 +1,30 @@
-This repository contains code to run the GitHub Docs site on docs.github.com, as well as the content that is displayed on the site. The code is written in JavaScript and TypeScript, and the content is primarily written in Markdown.
+---
+applyTo: "content/**,data/**,**/*.md"
+---
 
-Changes to files in `src/*` or files with `.ts` or `.js` extensions are likely code-related changes. Please follow the engineering guidelines below when making changes to these files.
+# Copilot content instructions for docs.github.com
 
-Changes to files in `content/*` and `data/*` are likely content-related changes. Content changes include updates to articles, reusable content, and data files that define variables used in articles. Please follow the content guidelines below when making changes to these files.
+**When to use**: Content editing, documentation writing, Markdown files
+**Key indicators**: Changes to .md files, creating articles, updating documentation
 
-## Engineering guidelines
+## Testing Content changes
 
-### Scripts
-
-All scripts can be found in `package.json`.
-
-To validate any code changes:
-   - `npm run tsc`
-   - `npm run build`
-   - `npm run prettier`
-   - `npm run lint`: you can include `-- --fix`
-
-To validate specific changes,
-  - `npm run test`: For all unit tests
-    - You can pass specific paths, e.g. `npm run test -- src/search/tests/ai-search-proxy`
-    - You can add `--silent=false` to include `console.log` debugging.
-  - `npm run build && npm run playwright-test -- playwright-rendering`: You need to build for changes outside of the test to be picked up. We use playwright for all rendering and end-to-end tests
-    - You can add `--ui` to keep open `localhost:4000` which can be viewed in a simple browser for debugging UI state.
-  - `npm run dev` to start the development server on `localhost:4000`.
-
-### Imports
-
-We use absolute imports, relative to the `src` directory, using the `@` symbol.
-
-For example, `getRedirect` which lives inn `src/redirects/lib/get-redirect.js` 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'`
-
-### Testing changes
-
-We use `vitest` to write unit tests. Tests live in their own files in the `tests` subdirectory of a source (src) directory, e.g. `src/search/tests/api-ai-search.ts`. 
-
-For integration tests, we can use the mock server in `src/tests/mocks/start-mock-server.ts` to mock exteneral requests. 
-
-For UI rendering tests, we use `playwright` and write tests in `src/fixtures/tests/playwright-rendering.spec.ts`
+Before committing content changes, always:
 
-## Content guidelines
+1. **Use the content linter** to validate content: `npm run lint-content -- --paths <file-paths>`
+2. **Check for proper variable usage** in your content
+3. **Verify [AUTOTITLE] links** point to existing articles
+4. **Run tests** on changed content: `npm run test -- src/content-render/tests/render-changed-and-deleted-files.js`
 
-### Bullet lists
+## Bullet lists
 
 The bulleted points in a bullet list should always be denoted in Markdown using an asterisk, not a hyphen.
 
-### Using variables
+## Using variables
 
 Within Markdown files, with the exception of the `title` field in the metadata at the start of a file, **always use the Liquid syntax variables rather than text** if a variable has been defined for that text. This ensures consistency and makes it easier to update product names globally.
 
-**Important**: Variables must be used in all content, including reusable content, data files, and regular articles. The only exceptions are the `title` field in frontmatter metadata and any file in the `content/site-policy` directory.
+**Important**: You must use variables in all content, including reusable content, data files, and regular articles. The only exceptions are the `title` field in frontmatter metadata and any file in the `content/site-policy` directory.
 
 For example:
 
@@ -64,7 +38,7 @@ For example:
 | `{% data variables.enterprise.prodname_managed_user %}`  | managed user account     | data/variables/enterprise.yml    |
 | `{% data variables.code-scanning.codeql_workflow %}`     | CodeQL analysis workflow | data/variables/code-scanning.yml |
 
-There are many more variables. These are stored in various YAML files within the `data/variables` directory.
+There are many more variables. We store these in various YAML files within the `data/variables` directory.
 
 **How to find variables**: Check the `data/variables` directory for existing variables before writing hardcoded text. Common variable files include:
 
@@ -73,7 +47,7 @@ There are many more variables. These are stored in various YAML files within the
 * `data/variables/enterprise.yml` - Enterprise-specific terms
 * `data/variables/code-scanning.yml` - Code scanning terms
 
-### Reusable text
+## Reusable text
 
 Reusables are long strings of reusable text, such as paragraphs or procedural lists, that are referenced in multiple content files. This makes it easier for us to maintain content and ensure that it is accurate across all files where the content is needed.
 
@@ -84,21 +58,21 @@ Examples where you should create a reusable:
 * You are documenting a new feature for a public preview. You need to create a note to display in all new articles about the new feature. Create a new reusable for the note and use it in all articles where it is needed.
 * You are documenting billing for a new feature and need to briefly mention how the feature is billed and link to content about billing in several articles. Create a new reusable with the brief mention and a link to the content on billing. Aim to use the reusable in all places where you want to mention billing for the feature.
 
-### Links to other articles
+## Links to other articles
 
 `[AUTOTITLE]` is the **only correct way** to specify the title of a linked article when that article is another page on the docs.github.com site.
 
 You can replace the placeholder link text `[AUTOTITLE]` only when linking to an anchor in the same article or when linking to an anchor in another article and the actual article title would be confusing.
 
-Never use the `{% link %}` Liquid tag for internal documentation links. The `[AUTOTITLE]` placeholder automatically pulls the correct title and ensures links remain valid when titles change.
+Never use the `{% link %}` Liquid tag for internal documentation links. The `[AUTOTITLE]` placeholder automatically pulls the correct title and ensures that links remain valid when titles change.
 
 Examples:
 
 * ✅ Correct: `For more information, see [AUTOTITLE](/copilot/using-github-copilot).`
 * ❌ Incorrect: `For more information, see [Using GitHub Copilot](/copilot/using-github-copilot).`
 * ❌ Incorrect: `For more information, see {% link /copilot/using-github-copilot %}.`
 
-### Parenthetical dashes
+## Parenthetical dashes
 
 Where a sentence of normal body text contains a parenthetical dash, the dash should always be an em dash without spaces at either side. This rule does not apply to text within code blocks.
 
@@ -110,31 +84,3 @@ Examples:
 * ❌ Incorrect: "The cat – which sat on a branch – smiled with a broad grin." (en dash with spaces)
 * ❌ Incorrect: "The cat-which sat on a branch-smiled with a broad grin." (hyphen without spaces)
 * ❌ Incorrect: "The cat - which sat on a branch - smiled with a broad grin." (hyphen with spaces)
-
-## Creating a pull request
-
-When creating a pull request as a result of a request to do so in Copilot Chat, the first line of the PR description should **always** be the following (in italics):
-
-`_This pull request was created as a result of the following prompt in Copilot Chat._`
-
-Then, within a collapsed section, quote the original prompt from Copilot Chat:
-
-```markdown
-<details>
-<summary>Original prompt - submitted by @GITHUB-USER-ID</summary>
-
-> [Original prompt text here]
-
-</details>
-```
-
-This helps reviewers understand the context and intent behind the automated changes.
-
-### Testing Content changes
-
-Before committing content changes, always:
-
-1. **Use the content linter** to validate content: `npm run lint-content -- --paths <file-paths>`
-2. **Check for proper variable usage** in your content
-3. **Verify [AUTOTITLE] links** point to existing articles
-4. **Run tests** on changed content: `npm run test -- src/content-render/tests/render-changed-and-deleted-files.js`

content/admin/all-releases.md

@@ -58,6 +58,7 @@ If you run analysis in an external CI system, we recommend using the same versio
 
 | {% data variables.product.prodname_ghe_server %} version | Recommended {% data variables.product.prodname_codeql_cli %} version |
 | ------------------------------------------------- | ---------------------- |
+| 3.18 | 2.21.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.21.4/)) |
 | 3.17 | 2.20.7 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.20.7/)) |
 | 3.16 | 2.20.3 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.20.3/)) |
 | 3.15 | 2.18.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.18.4/)) |
@@ -77,6 +78,7 @@ For instances with {% data variables.product.prodname_actions %} enabled, self-h
 
 | {% data variables.product.prodname_ghe_server %} version | Minimum Runner version |
 | ------------------------------------------------- | ---------------------- |
+| 3.18 | 2.324.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.324.0)) |
 | 3.17 | 2.322.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.322.0)) |
 | 3.16 | 2.321.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.321.0)) |
 | 3.15 | 2.319.1 ([release notes](https://github.com/actions/runner/releases/tag/v2.319.1)) |

content/admin/guides.md

@@ -70,7 +70,7 @@ includeGuides:
   - /admin/upgrading-your-instance/preparing-to-upgrade/enabling-automatic-update-checks
   - /admin/monitoring-and-managing-your-instance/configuring-high-availability/initiating-a-failover-to-your-replica-appliance
   - /admin/monitoring-and-managing-your-instance/monitoring-your-instance/recommended-alert-thresholds
-  - /admin/monitoring-and-managing-your-instance/monitoring-your-instance/setting-up-external-monitoring
+  - /admin/monitoring-and-managing-your-instance/monitoring-your-instance/collectd-metrics/setting-up-external-monitoring-with-collectd
   - /admin/upgrading-your-instance/preparing-to-upgrade/overview-of-the-upgrade-process
   - /admin/upgrading-your-instance/preparing-to-upgrade/upgrade-requirements
   - /admin/upgrading-your-instance/preparing-to-upgrade/taking-a-snapshot

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-monitoring-your-instance.md

@@ -0,0 +1,42 @@
+---
+title: About monitoring your instance
+intro: 'You can configure monitoring and alerting so that you''re aware of potential issues before they negatively impact application performance or availability.'
+versions:
+  ghes: '*'
+topics:
+  - Enterprise
+shortTitle: About monitoring
+---
+
+## Metrics
+
+{% ifversion ghes-opentelemetry %}OpenTelemetry metrics were introduced in {% data variables.product.prodname_ghe_server %} 3.18 and are the future foundation for monitoring your {% data variables.product.prodname_ghe_server %} instance. {% endif %}
+Collectd metrics {% ifversion ghes-opentelemetry %}will continue to be gathered by default, but we expect collectd metrics to be discontinued in a future release.{% else %}provide monitoring capabilities for your {% data variables.product.prodname_ghe_server %} instance.{% endif %}
+
+{% ifversion ghes-opentelemetry %}For more information about OpenTelemetry metrics, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/opentelemetry-metrics/about-opentelemetry-metrics).{% endif %}
+
+For more information about Collectd metrics, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/collectd-metrics/about-collectd-metrics).
+
+## Dashboards
+
+The {% data variables.enterprise.management_console %} provides built-in dashboards that visualize metrics to help you troubleshoot performance issues and better understand how your {% data variables.product.prodname_ghe_server %} appliance is being used. The data behind the graphs is gathered by the monitoring services and sampled regularly.
+
+For more information about the monitor dashboards, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-the-monitor-dashboards).
+
+## System Logs
+
+{% data variables.product.prodname_ghe_server %} maintains system logs that can be used to monitor system events and troubleshoot issues. These logs provide detailed information about various system processes and can be valuable for debugging and monitoring purposes.
+
+For more information about system logs, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/about-system-logs).
+
+## Troubleshooting resource allocation problems
+
+Resource allocation problems can impact the performance and availability of your {% data variables.product.prodname_ghe_server %} instance. Understanding how to identify and resolve these issues is crucial for maintaining optimal system performance.
+
+For more information about troubleshooting resource allocation problems, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/troubleshooting-resource-allocation-problems).
+
+## Generating a Health Check for your enterprise
+
+A health check provides a comprehensive overview of your {% data variables.product.prodname_ghe_server %} instance's current state and can help identify potential issues before they become critical.
+
+For more information about generating a health check, see [AUTOTITLE](/admin/monitoring-and-managing-your-instance/monitoring-your-instance/generating-a-health-check-for-your-enterprise).