Merge branch 'main' into fix/nuget-registry-url-43529

Author: Sharra-writes

CHANGELOG.md

@@ -1,5 +1,21 @@
 # Docs changelog
 
+**27 March 2026**
+
+We've introduced a new discovery landing page design for all the top-level doc sets on docs.github.com. The landing pages highlight recommended articles and give users the ability to filter articles by category with a drop down menu. Every article across the site now includes category metadata, making it easier to browse doc sets without relying solely on search. This replaces the previous product-landing layout across 35 doc sets.
+
+<hr>
+
+**26 March 2026**
+
+If you use both Copilot CLI and VS Code, when you start the CLI it will automatically connect to a currently open VS Code workspace that matches the directory in which you're using the CLI. You can also manually connect to VS Code by using the `/ide` slash command.
+
+This new article documents this feature and outlines the benefits of sharing context, trust settings, and output between Copilot CLI and VS Code:
+
+[Connecting GitHub Copilot CLI to VS Code](https://docs.github.com/en/copilot/how-tos/copilot-cli/connecting-vs-code)
+
+<hr>
+
 **23 March 2026**
 
 We've added an article with details of the various command-line options for allowing/denying tools that Copilot CLI can use.

Dockerfile

@@ -10,7 +10,7 @@
 # ---------------------------------------------------------------
 # To update the sha:
 # https://github.com/github/gh-base-image/pkgs/container/gh-base-image%2Fgh-base-noble
-FROM ghcr.io/github/gh-base-image/gh-base-noble:20260320-170214-g814cb7830@sha256:90350e63f9b56ec3f60f5ef9f51b489c4eef6462c7727e0d6729a1c8d95a4aa7 AS base
+FROM ghcr.io/github/gh-base-image/gh-base-noble:20260326-105710-g59112a0a7@sha256:ba809251141daf76a02c7c064ae2c3b27a904f2f62b16582f62fe4328267f38f AS base
 
 # Install curl for Node install and determining the early access branch
 # Install git for cloning docs-early-access & translations repos

config/kubernetes/default/deployments/webapp.yaml

@@ -22,6 +22,7 @@ spec:
         ad.datadoghq.com/tolerate-unready: 'true'
     spec:
       dnsPolicy: Default
+      terminationGracePeriodSeconds: 60
       containers:
         - name: webapp
           image: docs-internal
@@ -67,18 +68,19 @@ spec:
             preStop:
               exec:
                 command: ['sleep', '5']
+          # See production/deployments/webapp.yaml for detailed comments on probe config.
           startupProbe:
             httpGet:
               path: /healthcheck
               port: http
-            initialDelaySeconds: 5
+            initialDelaySeconds: 30
             periodSeconds: 5
-            failureThreshold: 12
+            failureThreshold: 30
             timeoutSeconds: 5
           readinessProbe:
-            timeoutSeconds: 5
-            periodSeconds: 10
-            failureThreshold: 3
             httpGet:
               path: /healthcheck
               port: http
+            periodSeconds: 10
+            failureThreshold: 5
+            timeoutSeconds: 5

config/kubernetes/production/deployments/webapp.yaml

@@ -3,15 +3,18 @@ kind: Deployment
 metadata:
   name: webapp
   annotations:
-    moda.github.net/allow-missing-ready-pods: '1'
+    moda.github.net/allow-missing-ready-pods: '0'
     moda.github.net/inject-unified-service-tag-env-var: docs-internal
 spec:
   replicas: 12
   strategy:
     type: RollingUpdate
     rollingUpdate:
-      maxUnavailable: 1
-      maxSurge: 2
+      # Don't kill old pods until new ones pass readiness.
+      # Prevents capacity loss during deploys. Safe because we're over-provisioned.
+      maxUnavailable: 0
+      # Percentage so it scales with replica count changes.
+      maxSurge: '25%'
   selector:
     matchLabels:
       app: webapp
@@ -28,6 +31,10 @@ spec:
         ad.datadoghq.com/tolerate-unready: 'true'
     spec:
       dnsPolicy: Default
+      # Hard deadline for pod shutdown after SIGTERM (includes preStop sleep).
+      # Default is 30s; 60s gives plenty of room for in-flight request draining
+      # and OTEL SDK shutdown even if DNS is slow.
+      terminationGracePeriodSeconds: 60
       containers:
         - name: webapp
           image: docs-internal
@@ -74,18 +81,34 @@ spec:
             preStop:
               exec:
                 command: ['sleep', '5']
+          # warmServer() loads ~3500 content files × 9 languages × 9 versions.
+          # Avg startup: ~25s, worst observed: ~48s (Datadog: docs.warm_server).
+          # Server does not listen until warmup completes, so probes fail at
+          # TCP level during boot — no app-level readiness flag needed.
           startupProbe:
             httpGet:
               path: /healthcheck
               port: http
-            initialDelaySeconds: 5
+            # Server can't respond until warmup finishes (~25s avg), so don't
+            # waste probes checking before that.
+            initialDelaySeconds: 30
             periodSeconds: 5
-            failureThreshold: 12
+            # Total runway: 30s + (30 × 5s) = 180s. Covers worst-case startup
+            # plus resource contention when multiple pods boot during a deploy.
+            failureThreshold: 30
             timeoutSeconds: 5
           readinessProbe:
-            timeoutSeconds: 5
-            periodSeconds: 10
-            failureThreshold: 3
             httpGet:
               path: /healthcheck
               port: http
+            periodSeconds: 10
+            # 5 × 10s = 50s before pulling pod from load balancer.
+            # Healthcheck is always-200 (no app-level logic), so failures
+            # mean the process is hung or under extreme pressure.
+            failureThreshold: 5
+            timeoutSeconds: 5
+          # No livenessProbe: healthcheck always returns 200 with no app-level
+          # checks, so a liveness probe would only catch a fully hung process.
+          # Readiness already removes hung pods from the load balancer, and we
+          # intentionally avoid liveness restarts — they risk killing pods
+          # during GC pauses or transient load spikes.

content/account-and-profile/tutorials/personalize-your-profile.md

@@ -118,7 +118,7 @@ You can set a status to display information about your current availability.
 1. In the "What's happening" field, type a status message.
 1. Optionally, to set an emoji status, click {% octicon "smiley" aria-label="Choose an emoji" %}, then click an emoji from the list.
 1. Optionally, if you'd like to share that you have limited availability, select "Busy."
-1. Select the **Clear status** dropdown menu, then click when you want your status to expire. If you don't select a status expiration, you will keep your status until you clear or edit your status.
+1. Select the **Expiration** dropdown menu, then click when you want your status to expire. If you don't select a status expiration, you will keep your status until you clear or edit your status.
 1. Select the **Visible to** dropdown menu, then click who you want your status visible to. If you don't select an organization, your status will be public.
 1. Click **Set status**.
 

content/actions/how-tos/write-workflows/choose-what-workflows-do/pass-job-outputs.md

@@ -65,3 +65,6 @@ contentType: how-tos
 To learn more about job outputs and the `needs` context, see the following sections of [AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idoutputs):
 * [`jobs.<job_id>.outputs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idoutputs)
 * [`jobs.<job_id>.needs`](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idneeds)
+
+To learn more about passing job outputs from one workflow to another, see the following section of [AUTOTITLE](/actions/how-tos/reuse-automations/reuse-workflows):
+* [Using outputs from a reusable workflow](/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow)

content/actions/reference/workflows-and-actions/workflow-syntax.md

@@ -279,7 +279,7 @@ The value of this parameter is a string specifying the data type of the input. T
 
 ## How permissions are calculated for a workflow job
 
-The permissions for the `GITHUB_TOKEN` are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request from a forked repository, and the **Send write tokens to workflows from pull requests** setting is not selected, the permissions are adjusted to change any write permissions to read only.
+The permissions for the `GITHUB_TOKEN` are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request event other than `pull_request_target` from a forked repository, and the **Send write tokens to workflows from pull requests** setting is not selected, the permissions are adjusted to change any write permissions to read only.
 
 ### Setting the `GITHUB_TOKEN` permissions for all jobs in a workflow
 

content/actions/tutorials/migrate-to-github-actions/automated-migrations/circleci-migration.md

@@ -52,7 +52,7 @@ The `configure` CLI command is used to set required credentials and options for
 
 1. Create a {% data variables.product.prodname_dotcom %} {% data variables.product.pat_v1 %}. For more information, see [AUTOTITLE](/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).
 
-   Your token must have the `workflow` scope.
+   Your token must have the `repo` and `workflow` scopes.
 
    After creating the token, copy it and save it in a safe location for later use.
 1. Create a CircleCI personal API token. For more information, see [Managing API Tokens](https://circleci.com/docs/managing-api-tokens/#creating-a-personal-api-token) in the CircleCI documentation.

content/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent.md

@@ -270,4 +270,6 @@ If you are using macOS or Linux, you may need to update your SSH client or insta
 
 {% data reusables.ssh.add-public-key-to-github %}
 
+## Further reading
 
+* [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/github-credential-types)

content/authentication/connecting-to-github-with-ssh/managing-deploy-keys.md

@@ -217,4 +217,5 @@ If your server needs to access multiple repositories, you can create a new accou
 
 ## Further reading
 
+* [AUTOTITLE](/organizations/managing-programmatic-access-to-your-organization/github-credential-types)
 * [Configuring notifications](/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#organization-alerts-notification-options)