Merge remote-tracking branch 'upstream/main' into casey/helm-versioning-strategy

# Conflicts:
#	content/code-security/reference/supply-chain-security/dependabot-options-reference.md

Author: casey-robertson-paypal

.github/CODEOWNERS

@@ -6,9 +6,5 @@
 # Site Policy
 content/site-policy/ @github/site-policy-admins
 
-# Enterprise
-data/release-notes/**/*.yml @github/docs-content-enterprise
-src/ghes-releases/lib/enterprise-dates.json @github/docs-content-enterprise
-
 # Requires review of #actions-oidc-integration, docs-engineering/issues/1506
 # content/actions/deployment/security-hardening-your-deployments/** @github/oidc

.github/actions/clone-translations/action.yml

@@ -11,56 +11,56 @@ runs:
   using: 'composite'
   steps:
     - name: Clone Spanish
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.es-es
         token: ${{ inputs.token }}
         path: translations/es-es
 
     - name: Clone Japanese
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.ja-jp
         token: ${{ inputs.token }}
         path: translations/ja-jp
 
     - name: Clone Portuguese
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.pt-br
         token: ${{ inputs.token }}
         path: translations/pt-br
 
     - name: Clone Simplified Chinese
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.zh-cn
         token: ${{ inputs.token }}
         path: translations/zh-cn
 
     - name: Clone Russian
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.ru-ru
         token: ${{ inputs.token }}
         path: translations/ru-ru
 
     - name: Clone French
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.fr-fr
         token: ${{ inputs.token }}
         path: translations/fr-fr
 
     - name: Clone Korean
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.ko-kr
         token: ${{ inputs.token }}
         path: translations/ko-kr
 
     - name: Clone German
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-internal.de-de
         token: ${{ inputs.token }}

.github/actions/create-workflow-failure-issue/action.yml

@@ -89,5 +89,6 @@ runs:
         gh issue create \
           --repo "$ISSUE_REPO" \
           --label "workflow-failure" \
+          --label "workflow-generated" \
           --title "[Workflow Failure] $WORKFLOW_NAME" \
           --body "$body"

.github/actions/get-docs-early-access/action.yml

@@ -19,7 +19,7 @@ runs:
       run: npm run what-docs-early-access-branch
 
     - name: Clone
-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+      uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
       with:
         repository: github/docs-early-access
         token: ${{ inputs.token }}

.github/actions/slack-alert/action.yml

@@ -2,28 +2,27 @@ name: Send Slack notification if workflow fails
 description: Send Slack notification if workflow fails
 
 inputs:
-  slack_channel_id:
-    description: Slack channel ID
-    required: true
   slack_token:
     description: Slack token
     required: true
+  slack_channel_id:
+    description: Slack channel ID. Defaults to the docs-alerts channel (CG5MJHMB2).
+    default: CG5MJHMB2 # docs-alerts
+    required: false
   message:
     description: The message to send to Slack
     default: The last '${{ github.workflow }}' run failed. See ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
     required: false
-  color:
-    description: The color of the Slack message
-    default: failure
-    required: false
 
 runs:
   using: composite
   steps:
     - name: Send Slack notification if workflow fails
-      uses: someimportantcompany/github-actions-slack-message@a975b440de2bcef178d451cc70d4c1161b5a30cd
+      uses: slackapi/slack-github-action@45a88b9581bfab2566dc881e2cd66d334e621e2c # v3.0.3
       with:
-        channel: ${{ inputs.slack_channel_id }}
-        bot-token: ${{ inputs.slack_token }}
-        color: ${{ inputs.color }}
-        text: ${{ inputs.message }}
+        method: chat.postMessage
+        token: ${{ inputs.slack_token }}
+        errors: true
+        payload: |
+          channel: ${{ toJSON(inputs.slack_channel_id) }}
+          text: ${{ toJSON(inputs.message) }}

.github/agents/driver-writer.md

@@ -0,0 +1,70 @@
+---
+
+name: "Driver-writer"
+description: "Use when writing, editing, or reviewing content for the Driver persona: enterprise administrators, platform engineers, billing managers, security leads, and others who enable developers at scale."
+
+---
+
+# Driver-writer Agent
+
+You are a writing assistant for the GitHub Docs team. You help writers create, edit, and review documentation that serves the **Driver persona**.
+
+A Driver is any GitHub user who supports the work of multiple developers by making changes to GitHub at scale. They remove barriers and enable developers to work efficiently while providing guardrails for compliance and security. Drivers include enterprise administrators, billing managers, application security leads, CI/CD administrators, tech leads, and OS maintainers.
+
+Our team prioritizes **self-serve enterprise customers** that use GitHub Enterprise but are not large enough to get dedicated support from a GitHub sales or success team. These customers rely heavily on documentation to set up and manage their enterprise. When making content decisions, optimize for this audience.
+
+Drivers come from two broad backgrounds, and content should account for both:
+
+* **IT administration**: Expects process and controls based on experience with other enterprise systems. May use terminology from other platforms when searching for information.
+* **Development**: Fewer preconceptions about enterprise administration. May have limited knowledge of best practices for setting up large systems.
+
+## What makes Driver content different
+
+Driver content is distinct from developer-focused (Builder) content in a few key ways. Apply these when writing or editing:
+
+### Frame value in terms of the enterprise, not individual productivity
+
+Builder content connects features to the developer's own workflow. Driver content should connect features to what Drivers care about: compliance, security posture, cost management, developer enablement at scale, and reducing operational risk.
+
+* Instead of: "You can restrict email notifications for your enterprise."
+* Write: "You can prevent your enterprise's information from leaking into personal email accounts."
+
+### Help Drivers make confident decisions
+
+Drivers often face choices with long-lasting, hard-to-reverse consequences (e.g., choosing between EMU and classic authentication, selecting an identity provider, structuring enterprises and organizations). Content should present enough context for the reader to choose confidently: what the tradeoffs are, what most enterprises do, and what cannot be changed later.
+
+### Write for people who manage GitHub, not people who use it to code
+
+Drivers are configuring, monitoring, and governing, not writing code. They are less likely to want code examples and more likely to need:
+
+* Clear explanations of how settings interact and propagate across an enterprise
+* Guidance on rollout sequence and dependencies between configuration steps
+* Visibility into what their developers will experience as a result of their changes
+
+### Be explicit about policy scope and cascade
+
+When writing about enterprise settings or policies, always clarify what level the setting operates at (enterprise, organization, repository) and how it cascades. Make it clear who controls the setting and whether lower levels can override it. When parallel articles exist for different levels (e.g., enterprise vs. org), keep the structure, terminology, and level of detail consistent between them.
+
+### Flag specific high-risk claims for verification
+
+Driver actions often affect an entire enterprise and can be hard to reverse, so a single inaccurate detail can have outsized consequences: a security gap, a compliance failure, unexpected cost, or an administrator locking themselves out. Do not flag an entire article as high-risk just because of its topic. Instead, identify the specific claims most likely to cause harm if wrong, and call each one out individually for the writer to verify.
+
+Pay closest attention to discrete, checkable claims in these areas:
+
+* Authentication and identity (e.g., specific SAML/SCIM attribute values, SSO setup steps)
+* Security and compliance policy behavior and enforcement
+* Billing, licensing, and spending controls (specific numbers, thresholds, what counts toward usage)
+* Irreversible or enterprise-wide configuration steps
+* Exact permission or role requirements for an action
+
+For example, in an article about configuring SSO, do not say "verify this entire article." Instead, flag the specific risky claims, e.g.: "Step 6 says to set the SAML `NameID` to the user's email. Confirm the exact required attribute with the identity team, since the wrong value will block all sign-ins."
+
+## Driver user journey
+
+Drivers move through these phases with GitHub. Content should meet them where they are:
+
+* **Evaluate**: Researching tools that add value for the team.
+* **Onboard**: Understanding best practices to configure the enterprise. Relying on documentation before reaching out to people.
+* **Adopt**: Monitoring rollout, managing licenses, evaluating ROI.
+* **Optimize**: Monitoring data, auditing configuration for efficiency.
+* **Sustain**: Promoting best practices, making minimal configuration changes.

.github/dependabot.yml

@@ -18,8 +18,6 @@ updates:
     ignore:
       # Because this is so dependent on the remote server we use
       - dependency-name: '@elastic/elasticsearch'
-      # Because whatever we have needs to match what @primer/react also uses
-      - dependency-name: 'styled-components'
       - dependency-name: '*'
         update-types:
           ['version-update:semver-patch', 'version-update:semver-minor']
@@ -31,6 +29,10 @@ updates:
       day: tuesday
     cooldown:
       default-days: 7
+    groups:
+      actions:
+        patterns:
+          - '*'
     ignore:
       - dependency-name: '*'
         update-types:

.github/instructions/code.instructions.md

@@ -4,10 +4,11 @@ applyTo: "src/**,.github/**,config/**,.devcontainer/**,**Dockerfile,package*.jso
 
 # 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.
+For code reviews and for creating or updating pull requests, follow the Guidelines, Tests, and Validate sections below.
 
 ## Guidelines
 
+- Before you make a new branch, make sure you have the latest changes by running `git checkout main && git pull`.
 - If available, use ripgrep (`rg`) instead of `grep`.
 - When using gh cli in double-quoted strings, escape backticks to prevent bash command substitution. In single-quoted strings, backticks do not need escaping.
 - 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
 - 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'`
 - For updates to the content linter, read important information in `src/content-linter/README.md`.
 - Do not use git force push, and avoid git rebase.
+- When reading issues and pull requests, read all comments as well.
+- 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.
+- When running in agentic mode, offer the human the option to wait for and review CI checks and automatic Copilot code review comments.
 
 ## Tests
 
@@ -79,30 +83,6 @@ Run the following commands to validate your changes:
 - `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 MCP or 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 GitHub Copilot 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 GitHub Copilot.
-
 ## Logger
 
 Use `createLogger` from `@/observability/logger` instead of `console.log` in server-side code.