Merge branch 'main' into patch-1

Author: mchammer01

.github/branch_protection_settings/main.json

@@ -41,7 +41,10 @@
       "workflows",
       "lint-code",
       "secret-scanning",
-      "pagelist"
+      "pagelist",
+      "docs-internal-docker-image / docs-internal-docker-image",
+      "docs-internal-docker-security / docs-internal-docker-security",
+      "docs-internal-moda-config-bundle / docs-internal-moda-config-bundle"
     ],
     "contexts_url": "https://api.github.com/repos/github/docs-internal/branches/main/protection/required_status_checks/contexts",
     "checks": [
@@ -85,7 +88,19 @@
       { "context": "workflows", "app_id": 15368 },
       { "context": "lint-code", "app_id": 15368 },
       { "context": "secret-scanning", "app_id": 15368 },
-      { "context": "pagelist", "app_id": 15368 }
+      { "context": "pagelist", "app_id": 15368 },
+      {
+        "context": "docs-internal-docker-image / docs-internal-docker-image",
+        "app_id": 15368
+      },
+      {
+        "context": "docs-internal-docker-security / docs-internal-docker-security",
+        "app_id": 15368
+      },
+      {
+        "context": "docs-internal-moda-config-bundle / docs-internal-moda-config-bundle",
+        "app_id": 15368
+      }
     ]
   },
   "restrictions": {

.github/workflows/azure-prod-build-deploy.yml

@@ -5,9 +5,6 @@ name: Azure Production - Build and Deploy
 # **Who does it impact**: All contributors.
 
 on:
-  push:
-    branches:
-      - main
   workflow_dispatch:
 
 permissions:

.github/workflows/codeowners-legal.yml

@@ -20,6 +20,7 @@ on:
 permissions:
   contents: read
   pull-requests: write
+  repository-projects: read
 
 jobs:
   codeowners-legal:
@@ -33,7 +34,7 @@ jobs:
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
         with:
           # Picking this number is a "best guess". If we make it too large,
-          # the checkout will take potentially unnecessariily long.
+          # the checkout will take potentially unnecessarily long.
           # This reduces the chance that tj-actions/changed-files has to
           # fetch deeper history. But if it needs to, it will.
           fetch-depth: 10
@@ -58,19 +59,14 @@ jobs:
           CHANGED_FILE_PATHS: ${{ steps.changed-files.outputs.all_changed_files }}
           CONTENT_TYPE: 'rai'
 
-      - name: Add Legal team as a reviewer
+      - name: Check for reviewers-legal label, add if missing and request review
         if: steps.checkContentType.outputs.containsContentType == 'true'
         env:
-          # The GH CLI uses a slightly different env name for
-          # the token than the GITHUB_TOKEN used by actions
-          GH_TOKEN: ${{ secrets.DOCS_BOT_PAT_WRITEORG_PROJECT }}
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           PR: ${{ github.event.pull_request.html_url }}
         run: |
-          has_reviewer=$(
-            gh pr view $PR --json reviews |
-            jq 'any(.reviews[]; select(length > 0))'
-          )
-          if ! $has_reviewer
-          then
+          labels=$(gh pr view ${{ github.event.pull_request.number }} --json labels --jq '.labels[].name')
+          if ! echo "$labels" | grep -q 'reviewers-legal'; then
             gh pr edit $PR --add-reviewer github/legal-product
+            gh pr edit $PR --add-label reviewers-legal
           fi

.github/workflows/purge-fastly.yml

@@ -5,6 +5,7 @@ name: Purge Fastly
 # **Who does it impact**: Writers and engineers.
 
 on:
+  deployment_status:
   workflow_dispatch:
     inputs:
       nuke_all:
@@ -16,9 +17,6 @@ on:
         description: "Comma separated languages. E.g. 'en,ja, es' (defaults to all)"
         required: false
         default: ''
-  push:
-    branches:
-      - main
 
 permissions:
   contents: read
@@ -29,11 +27,12 @@ env:
 
 jobs:
   send-purges:
+    # Run when workflow_dispatch is the event (manual) or when deployment_status is the event (automatic) and it's a successful production deploy
     if: >-
       ${{
         github.repository == 'github/docs-internal' &&
-        (github.event_name != 'workflow_run' ||
-        github.event.workflow_run.conclusion == 'success')
+        (github.event_name != 'deployment_status' ||
+         github.event.deployment_status.state == 'success' && github.event.deployment_status.environment == 'production')
       }}
     runs-on: ubuntu-latest
     steps:

config/kubernetes/production/deployments/webapp.yaml

@@ -23,10 +23,10 @@ spec:
           image: docs-internal
           resources:
             requests:
-              cpu: 4000m
-              memory: 5Gi
+              cpu: 8000m
+              memory: 10Gi
             limits:
-              cpu: 4000m
+              cpu: 16000m
               memory: 14Gi
           ports:
             - name: http

config/moda/deployment.yaml

@@ -1,13 +1,36 @@
-required_builds:
-  - docs-internal-moda-config-bundle / docs-internal-moda-config-bundle
-  - docs-internal-docker-image / docs-internal-docker-image
-  - docs-internal-docker-security / docs-internal-docker-security
+# Deploy configuration reference: https://thehub.github.com/epd/engineering/products-and-services/internal/moda/reference/deployment-yaml/
+
 environments:
   - name: production
-    auto_deploy: true
+    require_pipeline: true
     cluster_selector:
       profile: general
       region: iad
+
+required_builds:
+  - docs-internal-moda-config-bundle / docs-internal-moda-config-bundle
+  - docs-internal-docker-image / docs-internal-docker-image
+  - docs-internal-docker-security / docs-internal-docker-security
+
+# Make the pipeline start automatically when a PR is enqueued
+auto_start_pipeline: production_rollout
+
+pipelines:
+  production_rollout:
+    thread_notifications: true
+    notify_users_via_dm: false
+    timeout: 1200
+    stages:
+      - name: full_production
+        kind: deployment
+        start_message: We are now going to deploy {{app}}/{{ref}}! Please pause or cancel the pipeline after the deploy if you want more time before auto-merging your pull request(s).
+        config:
+          environment: production
+          timeout: 1200
+        # gates:
+        #   - kind: timer
+        #     duration: 1200
+
 notifications:
   slack_channels:
     - '#docs-ops'

content/actions/administering-github-actions/usage-limits-billing-and-administration.md

@@ -45,7 +45,7 @@ There are some limits on {% data variables.product.prodname_actions %} usage whe
 * **Job execution time** - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
 {% data reusables.actions.usage-workflow-run-time %}
 {% data reusables.actions.usage-api-requests %}
-* **Webhook rate limit** - Each repository is limited to 1500 triggered events every 10 seconds.
+* **Webhook rate limit** - Each repository is limited to 1500 events triggering a workflow run every 10 seconds. When the limit is reached, the workflow runs that were supposed to be triggered by the webhook events will be blocked and will not be queued.
 * **Concurrent jobs** - The number of concurrent jobs you can run in your account depends on your {% data variables.product.prodname_dotcom %} plan, as well as the type of runner used. If exceeded, any additional jobs are queued.
 
   **Standard {% data variables.product.prodname_dotcom %}-hosted runners**

content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md

@@ -124,6 +124,7 @@ The following processor architectures are supported for the self-hosted runner a
 
 ## Supported actions on self-hosted runners
 
+All `actions/setup-LANGUAGE` action repositories currently support three platforms: macOS, Windows, and Ubuntu.
 Some extra configuration might be required to use actions from {% data variables.product.github %} with {% data variables.product.prodname_ghe_server %}, or to use the `actions/setup-LANGUAGE` actions with self-hosted runners that do not have internet access. For more information, see [AUTOTITLE](/admin/github-actions/managing-access-to-actions-from-githubcom) and contact your {% data variables.product.prodname_enterprise %} site administrator.
 
 {% endif %}

content/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job.md

@@ -49,7 +49,8 @@ The scripts are automatically executed when the runner has the following environ
 * `ACTIONS_RUNNER_HOOK_JOB_STARTED`: The script defined in this environment variable is triggered when a job has been assigned to a runner, but before the job starts running.
 * `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`: The script defined in this environment variable is triggered at the end of the job, after all the steps defined in the workflow have run.
 
-To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software). For example, the following `.env` entry will have the runner automatically run a script, saved as `/opt/runner/cleanup_script.sh` on the runner machine, before each job runs:
+To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software). Note that any change to the `.env` file will require restarting the runner.  
+For example, the following `.env` entry will have the runner automatically run a script, saved as `/opt/runner/cleanup_script.sh` on the runner machine, before each job runs:
 
 ```bash
 ACTIONS_RUNNER_HOOK_JOB_STARTED=/opt/runner/cleanup_script.sh

content/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow.md

@@ -17,7 +17,7 @@ shortTitle: Use runners in a workflow
 
 You can target self-hosted runners for use in a workflow based on the labels assigned to the runners{% ifversion target-runner-groups %}, or their group membership, or a combination of these{% endif %}.
 
->[!NOTE]Actions Runner Controller does not support multiple labels, only the name of the runner can be used in place of a label
+>[!IMPORTANT]Runner Scale Sets do not support multiple labels, only the name of the runner can be used in place of a label. See [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller).
 
 ## About self-hosted runner labels
 
@@ -109,9 +109,9 @@ These labels operate cumulatively, so a self-hosted runner must have all four la
 
 ## Routing precedence for self-hosted runners
 
-When routing a job to a self-hosted runner, {% data variables.product.prodname_dotcom %} looks for a runner that matches the job's `runs-on` labels{% ifversion target-runner-groups %} and/or groups{% endif %}:
+When routing a job to a self-hosted runner, {% data variables.product.prodname_dotcom %} looks for a runner that matches the job's `runs-on` labels{% ifversion target-runner-groups %} and groups{% endif %}:
 
-* If {% data variables.product.prodname_dotcom %} finds an online and idle runner that matches the job's `runs-on` labels{% ifversion target-runner-groups %} and/or groups{% endif %}, the job is then assigned and sent to the runner.
+* If {% data variables.product.prodname_dotcom %} finds an online and idle runner that matches the job's `runs-on` labels{% ifversion target-runner-groups %} and groups{% endif %}, the job is then assigned and sent to the runner.
   * If the runner doesn't pick up the assigned job within 60 seconds, the job is re-queued so that a new runner can accept it.
-* If {% data variables.product.prodname_dotcom %} doesn't find an online and idle runner that matches the job's `runs-on` labels {% ifversion target-runner-groups %} and/or groups{% endif %}, then the job will remain queued until a runner comes online.
+* If {% data variables.product.prodname_dotcom %} doesn't find an online and idle runner that matches the job's `runs-on` labels {% ifversion target-runner-groups %} and groups{% endif %}, then the job will remain queued until a runner comes online.
 * If the job remains queued for more than 24 hours, the job will fail.

content/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md

@@ -66,7 +66,7 @@ For more information on reviewing jobs that reference an environment with requir
 
 ### Wait timer
 
-Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 1 and 43,200 (30 days).
+Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 1 and 43,200 (30 days). Wait time will not count towards your billable time.
 
 {% ifversion fpt %}
 

content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-travis-ci-to-github-actions.md

@@ -183,13 +183,7 @@ The concurrent jobs and workflow execution times in {% data variables.product.pr
 
 ### Using different languages in {% data variables.product.prodname_actions %}
 
-When working with different languages in {% data variables.product.prodname_actions %}, you can create a step in your job to set up your language dependencies. For more information about working with a particular language, see the specific guide:
-* [Building and testing Node.js](/actions/automating-builds-and-tests/building-and-testing-nodejs)
-* [Building and testing Python](/actions/automating-builds-and-tests/building-and-testing-python)
-* [Building and testing PowerShell](/actions/automating-builds-and-tests/building-and-testing-powershell)
-* [Building and testing Java with Maven](/actions/automating-builds-and-tests/building-and-testing-java-with-maven)
-* [Building and testing Java with Gradle](/actions/automating-builds-and-tests/building-and-testing-java-with-gradle)
-* [Building and testing Java with Ant](/actions/automating-builds-and-tests/building-and-testing-java-with-ant)
+When working with different languages in {% data variables.product.prodname_actions %}, you can create a step in your job to set up your language dependencies. For more information about working with a particular language, see [AUTOTITLE](/actions/use-cases-and-examples/building-and-testing).
 
 ## Executing scripts
 

content/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform.md

@@ -29,6 +29,16 @@ This guide gives an overview of how to configure GCP to trust {% data variables.
 
 {% data reusables.actions.oidc-on-ghecom %}
 
+{% ifversion ghes %}
+{% data reusables.actions.oidc-endpoints %}
+  <!-- This note is indented to align with the above reusable. -->
+
+  > [!NOTE]
+  > Google Cloud Platform does not have fixed IP ranges defined for these endpoints.
+
+* Make sure that the value of the issuer claim that's included with the JSON Web Token (JWT) is set to a publicly routable URL. For more information, see [AUTOTITLE](/enterprise-server@latest/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect).
+{% endif %}
+
 ## Adding a Google Cloud Workload Identity Provider
 
 To configure the OIDC identity provider in GCP, you will need to perform the following configuration. For instructions on making these changes, refer to [the GCP documentation](https://github.com/google-github-actions/auth).

content/actions/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller.md

@@ -9,6 +9,8 @@ redirect_from:
   - /actions/security-guides/enforcing-artifact-attestations-with-a-kubernetes-admission-controller
 ---
 
+>[!NOTE] Before proceeding, ensure you have enabled build provenance for container images, including setting the `push-to-registry` attribute in the [`attest-build-provenance` action](https://github.com/actions/attest-build-provenance) as documented in [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images). This is required for the Policy Controller to verify the attestation.
+
 ## About Kubernetes admission controller
 
 [Artifact attestations](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds) enable you to create unfalsifiable provenance and integrity guarantees for the software you build. In turn, people who consume your software can verify where and how your software was built.
@@ -19,6 +21,12 @@ Using the open source [Sigstore Policy Controller](https://docs.sigstore.dev/pol
 
 To [install the controller](#getting-started-with-kubernetes-admission-controller), we offer [two Helm charts](https://github.com/github/artifact-attestations-helm-charts): one for deploying the Sigstore Policy Controller, and another for loading the GitHub trust root and a default policy.
 
+### About image verification
+
+When the Policy Controller is installed, it will intercept all image pull requests and verify the attestation for the image. The attestation must be stored in the image registry as an [OCI attached artifact](https://oras.land/docs/concepts/reftypes/) containing a [Sigstore Bundle](https://docs.sigstore.dev/about/bundle/) which contains the attestation and cryptographic material (e.g. certificates and signatures) used to verify the attestation. A verification process is then performed that ensures the image was built with the specified build provenance and matches any policies enabled by the cluster administrator.
+
+In order for an image to be verifiable, it must have a valid provenance attestation in the registry, which can be done by enabling the `push-to-registry: true` attribute in the `actions/attest-build-provenance` action. See [Generating build provenance for container images](/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds#generating-build-provenance-for-container-images) for more details on how to generate attestations for container images.
+
 ### About trust roots and policies
 
 The Sigstore Policy Controller is primarily configured with trust roots and policies, represented by the Custom Resources `TrustRoot` and `ClusterImagePolicy`. A `TrustRoot` represents a trusted distribution channel for the public key material used to verify attestations. A `ClusterImagePolicy` represents a policy for enforcing attestations on images.

content/actions/sharing-automations/creating-actions/creating-a-composite-action.md

@@ -155,7 +155,7 @@ Before you begin, you'll create a repository on {% data variables.product.github
 
 The following workflow code uses the completed hello world action that you made in [AUTOTITLE](/actions/creating-actions/creating-a-composite-action#creating-an-action-metadata-file).
 
-Copy the workflow code into a `.github/workflows/main.yml` file in another repository, replacing `actions` and `SHA` with the repository owner and the SHA of the commit you want to use, respectively. You can also replace the `who-to-greet` input with your name.
+Copy the workflow code into a `.github/workflows/main.yml` file in another repository, replacing `OWNER` and `SHA` with the repository owner and the SHA of the commit you want to use, respectively. You can also replace the `who-to-greet` input with your name.
 
 ```yaml copy
 on: [push]

content/actions/use-cases-and-examples/building-and-testing/building-and-testing-java-with-maven.md

@@ -117,7 +117,7 @@ You can cache your dependencies to speed up your workflow runs. After a successf
 ```yaml copy
 steps:
   - uses: {% data reusables.actions.action-checkout %}
-  - name: Set up JDK 11
+  - name: Set up JDK 17
     uses: {% data reusables.actions.action-setup-java %}
     with:
       java-version: '17'

content/actions/writing-workflows/quickstart.md

@@ -5,6 +5,7 @@ allowTitleToDifferFromFilename: true
 redirect_from:
   - /actions/getting-started-with-github-actions/starting-with-preconfigured-workflow-templates
   - /actions/quickstart
+  - /actions/getting-started-with-github-actions
 versions:
   fpt: '*'
   ghes: '*'

content/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh.md

@@ -66,7 +66,7 @@ Host HOSTNAME
 
 ## Accessing the administrative shell using the local console
 
-In an emergency situation, for example if SSH is unavailable, you can access the administrative shell locally. Sign in as the `admin` user and use the password established during initial setup of {% data variables.product.prodname_ghe_server %}.
+In an emergency situation, for example if SSH is unavailable, you can access the administrative shell locally if your hypervisor provides console access. Press `Alt` + `F2` to switch to an interactive prompt, then sign in as the `admin` user and use the password established during initial setup of {% data variables.product.prodname_ghe_server %}.
 
 ## Access limitations for the administrative shell