Merge branch 'main' into fixing-security-docs

Author: sharesth23

.github/workflows/benchmark-pages.yml

@@ -44,7 +44,7 @@ jobs:
           npx tsx src/workflows/benchmark-pages.ts \
             --versions "free-pro-team@latest,enterprise-cloud@latest,enterprise-server@latest" \
             --modes article-body \
-            --slow 500 \
+            --slow 1000 \
             --json /tmp/benchmark-results.json | tee /tmp/benchmark-output.txt
 
       - name: Check results and create issue if needed
@@ -108,7 +108,7 @@ jobs:
             echo "**Total pages:** $TOTAL"
             echo "**Stats:** p50=${P50}ms · p99=${P99}ms · max=${MAX}ms"
             echo "**Errors:** $ERRORS"
-            echo "**Slow (≥500ms):** $SLOW"
+            echo "**Slow (≥1000ms):** $SLOW"
           } > "$BODY_FILE"
 
           if [ "$ERRORS" -gt 0 ]; then

.github/workflows/notify-release-pms.yml

@@ -0,0 +1,76 @@
+name: Notify release PMs
+
+# **What it does**: Posts review notification comments on release issues
+# in github/releases for generated GHES release notes.
+# **Why we have it**: So comments are always posted by docs-bot, without
+# needing to distribute a PAT to individual team members.
+# **Who does it impact**: Docs content (GHES release DRIs).
+
+on:
+  workflow_dispatch:
+    inputs:
+      release:
+        description: 'GHES release version (e.g., 3.21)'
+        type: string
+        required: true
+      pr:
+        description: 'docs-internal PR number containing the release notes'
+        type: string
+        required: true
+      release_type:
+        description: 'Release type (auto-detects from files if not specified)'
+        type: choice
+        options:
+          - auto
+          - rc
+          - ga
+        default: 'auto'
+      review_date:
+        description: 'Override review deadline (YYYY-MM-DD, optional)'
+        type: string
+        required: false
+      dry_run:
+        description: 'Preview comments in the workflow log without posting them'
+        type: boolean
+        default: false
+
+permissions:
+  contents: read
+
+jobs:
+  notify:
+    name: Notify release PMs
+    if: github.repository == 'github/docs-internal'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository code
+        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
+
+      - uses: ./.github/actions/node-npm-setup
+
+      - name: Post notification comments
+        env:
+          DOCS_BOT_PAT_BASE: ${{ secrets.DOCS_BOT_PAT_BASE }}
+          INPUT_RELEASE: ${{ inputs.release }}
+          INPUT_PR: ${{ inputs.pr }}
+          INPUT_RELEASE_TYPE: ${{ inputs.release_type }}
+          INPUT_REVIEW_DATE: ${{ inputs.review_date }}
+          INPUT_DRY_RUN: ${{ inputs.dry_run }}
+        run: |
+          args=(--release "$INPUT_RELEASE" --pr "$INPUT_PR")
+
+          if [[ "$INPUT_RELEASE_TYPE" == "rc" ]]; then
+            args+=(--rc)
+          elif [[ "$INPUT_RELEASE_TYPE" == "ga" ]]; then
+            args+=(--ga)
+          fi
+
+          if [[ -n "$INPUT_REVIEW_DATE" ]]; then
+            args+=(--review-date "$INPUT_REVIEW_DATE")
+          fi
+
+          if [[ "$INPUT_DRY_RUN" == "true" ]]; then
+            args+=(--dry-run)
+          fi
+
+          npm run notify-release-pms -- "${args[@]}"

.github/workflows/purge-fastly.yml

@@ -39,6 +39,7 @@ jobs:
       - uses: ./.github/actions/node-npm-setup
 
       - name: Wait for production to match build number
+        if: github.event_name != 'workflow_dispatch'
         run: |
           needs=$(git rev-parse HEAD)
           start_time=$(date +%s)

CHANGELOG.md

@@ -1,5 +1,16 @@
 # Docs changelog
 
+**15 April 2026**
+
+LSP servers greatly improve Copilot CLI's ability to work with your code. For example, when Copilot renames a symbol throughout a project it can do this more quickly and reliably if it has access to an LSP server for the language the code is written in.
+
+We've added documentation to explain LSP servers in greater detail and show how to install these for Copilot CLI:
+
+* [Using LSP servers with GitHub Copilot CLI](https://docs.github.com/copilot/concepts/agents/copilot-cli/lsp-servers)
+* [Adding LSP servers for GitHub Copilot CLI](https://docs.github.com/copilot/how-tos/copilot-cli/set-up-copilot-cli/add-lsp-servers)
+
+<hr>
+
 **13 April 2026**
 
 To coincide with the release of the ability to [steer your Copilot CLI sessions remotely](https://github.blog/changelog/2026-04-13-remote-control-cli-sessions-on-web-and-mobile-in-public-preview/) (from GitHub.com, or from GitHub Mobile), we have added these new articles:

config/kubernetes/production/deployments/webapp.yaml

@@ -40,18 +40,18 @@ spec:
           image: docs-internal
           resources:
             requests:
-              cpu: 1250m
+              cpu: 1500m
               # Absolute minimum to start app is 1000m
               # Node is single-threaded but we want more CPUs
               # for OS and image resizing, and other binary executions
               # Better to increase replicas or memory than CPU
-              memory: 8.0Gi
+              memory: 5000Mi
               # Absolute minimum to start app is 4500Mi
               # Would increase with more pages, versions, or languages supported
               # The additional memory helps during traffic surges
             limits:
               cpu: 8000m
-              memory: 16.0Gi
+              memory: 14.0Gi
           ports:
             - name: http
               containerPort: 4000

content/billing/how-tos/set-up-budgets.md

@@ -136,3 +136,4 @@ You can edit or delete a budget at any time, but you cannot change the scope of
 1. Navigate to the "Budgets and alerts" view. See [Viewing budgets](#viewing-budgets).
 1. In the list of budgets, click {% octicon "kebab-horizontal" aria-label="View actions" %} next to the budget you want to edit, and click **{% octicon "pencil" aria-hidden="true" aria-label="pencil" %} Edit** or **{% octicon "trash" aria-hidden="true" aria-label="trash" %} Delete**.
 1. Follow the prompts.
+

content/codespaces/troubleshooting/troubleshooting-included-usage.md

@@ -106,3 +106,4 @@ If the dev container for the current codespace was built from the default image,
 
   Alternatively, you can check which repositories have prebuilds by reviewing a usage report. See [Understanding your {% data variables.product.prodname_codespaces %} usage](#understanding-your-codespaces-usage) above.
 * Storage of containers built from the default dev container image for codespaces is free of charge and does not reduce your included storage. You can therefore avoid your storage allowance being consumed by your dev container by using the default image in your dev container configuration, rather than specifying a more specialized image. See [AUTOTITLE](/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers#using-the-default-dev-container-configuration) and [Storage usage for your base dev container](#storage-usage-for-your-base-dev-container) above.
+

content/contributing/style-guide-and-content-model/index.md

@@ -10,7 +10,7 @@ children:
     - /about-the-content-model
     - /contents-of-a-github-docs-article
     - /conceptual-content-type
-    - /referential-content-type
+    - /reference-content-type
     - /how-to-content-type
     - /troubleshooting-content-type
     - /release-note-content-type

…ontent-model/referential-content-type.md …-content-model/reference-content-type.mdcontent/contributing/style-guide-and-content-model/referential-content-type.md renamed to content/contributing/style-guide-and-content-model/reference-content-type.md content/contributing/style-guide-and-content-model/referential-content-type.md renamed to content/contributing/style-guide-and-content-model/reference-content-type.md

@@ -1,24 +1,27 @@
 ---
-title: Referential content type
-intro: Referential content provides detailed information that people need while they are actively using a feature.
+title: Reference content type
+intro: Reference content provides detailed information that people need while they are actively using a feature.
 versions:
   fpt: '*'
   ghec: '*'
   ghes: '*'
 category:
   - Follow the style guide and content model
 ---
+Reference content is consulted for specific pieces of information. It’s information you can quickly check, meaning there’s less emphasis on sentences and paragraphs.  
 
-We create referential articles and referential sections within other articles.
-* Some major subjects may require their own referential article, especially if there is a large amount of referential content, such as for search syntax or YAML syntax in {% data variables.product.prodname_actions %}.
-* For smaller amounts of content or more specific information, like a list of a feature’s supported languages or hardware requirements, use referential sections in context within procedural or conceptual articles.
+Reference includes information that may be best represented in tables, lists, or other structured formats. We might think of reference as including our autogenerated pipeline content and other content that could potentially be automated. 
 
-## How to write referential content
+Reference content appears in reference articles and reference sections within other articles.
+* Some major subjects may require their own reference article, especially if there is a large amount of reference content, such as for search syntax or YAML syntax in {% data variables.product.prodname_actions %}.
+* For smaller amounts of content or more specific information, like a list of a feature’s supported languages or hardware requirements, use reference sections in context within procedural or conceptual articles.
 
-For the referential content template, see [AUTOTITLE](/contributing/writing-for-github-docs/templates#referential-article-template).
+## How to write reference content
 
-* Write a sentence or an entire conceptual section to introduce the referential content.
-* Present the actual referential content clearly and consistently.
+For the reference content template, see [AUTOTITLE](/contributing/writing-for-github-docs/templates#reference-article-template).
+
+* Write a sentence or an entire conceptual section to introduce the reference content.
+* Present the actual reference content clearly and consistently.
 * For subjects with a single element to explain, use a list.
   * Example: [AUTOTITLE](/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization#repository-roles-for-organizations)
 * For subjects with multiple elements to explain, use a table.
@@ -33,14 +36,15 @@ For the referential content template, see [AUTOTITLE](/contributing/writing-for-
 * Referential articles or headers of referential sections clearly describe the contents of the section, and generally begin with nouns.
 * Titles include enough information to be accessible to novice users and fully describe the contents of each section.
 * Titles avoid stacked nouns - use prepositions to break up long strings of nouns.
+* Short titles should be one word or a short noun phrase. Example: "AI Models". 
 
-## Examples of referential content
+## Examples of reference content
 
-* Referential articles
-  * [AUTOTITLE](/get-started/accessibility/keyboard-shortcuts)
+* Reference articles
+  * [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/audit-log-events-for-your-organization)
   * [AUTOTITLE](/enterprise-cloud@latest/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
   * [AUTOTITLE](/free-pro-team@latest/rest/reference/billing) in the REST API documentation
   * [AUTOTITLE](/graphql/reference/mutations) in the GraphQL API documentation
-* Referential sections within other articles
+* Reference sections within other articles
   * "Supported languages" in [AUTOTITLE](/free-pro-team@latest/get-started/using-github/github-mobile#supported-languages-for-github-mobile)
   * "Hardware considerations" in [AUTOTITLE](/enterprise-server@latest/admin/installation/installing-github-enterprise-server-on-aws#hardware-considerations)

content/contributing/writing-for-github-docs/templates.md

@@ -59,9 +59,9 @@ Optionally, include a bulleted list of related articles the user can reference t
 
 <!-- markdownlint-enable search-replace -->
 
-## Referential article template
+## Reference article template
 
-Use the content model for full instructions and examples on how to write referential content. For more information, see [AUTOTITLE](/contributing/style-guide-and-content-model/referential-content-type).
+Use the content model for full instructions and examples on how to write reference content. For more information, see [AUTOTITLE](/contributing/style-guide-and-content-model/reference-content-type).
 
 <!-- markdownlint-disable search-replace -->
 
@@ -77,8 +77,8 @@ versions:
 ---
 
 {% comment %}
-Follow the guidelines in https://docs.github.com/contributing/writing-for-github-docs/content-model#referential to write this article.-- >
-Great intros give readers a quick understanding of what's in the article, so they can tell whether it's relevant to them before moving ahead. For more tips, see https://docs.github.com/contributing/writing-for-github-docs/content-model
+Follow the guidelines in https://docs.github.com/contributing/writing-for-github-docs/content-model to write this article.-- >
+Great intros give readers a quick understanding of what's in the article, so they can tell whether it's relevant to them before moving ahead. For more tips, see https://docs.github.com/en/contributing/style-guide-and-content-model/contents-of-a-github-docs-article#intro
 For product callout info, see https://github.com/github/docs/tree/main/content#product
 For product version instructions, see https://github.com/github/docs/tree/main/content#versioning
 Remove these comments from your article file when you're done writing