Repo sync

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/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment.md

@@ -28,7 +28,7 @@
 
 You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the deployment protection rules pass.
 
 {% ifversion actions-break-glass %}Optionally, you can bypass an environment's protection rules and force all pending jobs referencing the environment to proceed. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/reviewing-deployments#bypassing-environment-protection-rules).{% endif %}
 
 {% ifversion fpt %}
 
@@ -41,7 +41,7 @@
 
 ## Deployment protection rules
 
 Deployment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use deployment protection rules to require a manual approval, delay a job, or restrict the environment to certain branches.{% ifversion actions-custom-deployment-protection-rules-beta %} You can also create and implement custom protection rules powered by {% data variables.product.prodname_github_apps %} to use third-party systems to control deployments referencing environments configured on {% data variables.product.github %}.
 
 Third-party systems can be observability systems, change management systems, code quality systems, or other manual configurations that you use to assess readiness before deployments are safely rolled out to environments.
 
@@ -66,7 +66,7 @@
 
 ### 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 %}
 
@@ -107,7 +107,7 @@
 
 {% endif %}
 
 {% ifversion actions-break-glass %}
 
 ### Allow administrators to bypass configured protection rules
 
@@ -123,7 +123,7 @@
 {% endif %}
 {% endif %}
 
 {% ifversion actions-custom-deployment-protection-rules-beta %}
 
 ### Custom deployment protection rules
 
@@ -195,12 +195,12 @@
    1. Select **Wait timer**.
    1. Enter the number of minutes to wait.
    1. Click **Save protection rules**.
 {%- ifversion actions-break-glass %}
 1. Optionally, disallow bypassing configured protection rules. For more information, see [Allow administrators to bypass configured protection rules](#allow-administrators-to-bypass-configured-protection-rules).
    1. Deselect **Allow administrators to bypass configured protection rules**.
    1. Click **Save protection rules**.
 {%- endif %}
 {%- ifversion actions-custom-deployment-protection-rules-beta %}
 1. Optionally, enable any custom deployment protection rules that have been created with {% data variables.product.prodname_github_apps %}. For more information, see [Custom deployment protection rules](#custom-deployment-protection-rules).
    1. Select the custom protection rule you want to enable.
    1. Click **Save protection rules**.

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/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
 

content/admin/managing-github-actions-for-your-enterprise/managing-access-to-actions-from-githubcom/about-using-actions-in-your-enterprise.md

@@ -45,21 +45,19 @@ Each action is a repository in the `actions` organization, and each action repos
 
 > [!NOTE]
 > * When using setup actions (such as `actions/setup-LANGUAGE`) on {% data variables.product.product_name %} with self-hosted runners, you might need to set up the tools cache on runners that do not have internet access. For more information, see [AUTOTITLE](/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access).
+> * All `actions/setup-LANGUAGE` action repositories currently support three platforms: macOS, Windows, and Ubuntu.
 > * When {% data variables.product.product_name %} is updated, bundled actions are automatically replaced with default versions in the upgrade package.
+> * Being bundled with {% data variables.product.prodname_ghe_server %} means the action is available within that environment, but it doesn’t automatically guarantee compatibility with all platforms or self-hosted runners.
 
 ## Configuring access to actions on {% data variables.product.prodname_dotcom_the_website %}
 
 {% data reusables.actions.access-actions-on-dotcom %}
 
 The recommended approach is to enable automatic access to all actions from {% data variables.product.prodname_dotcom_the_website %}. You can do this by using {% data variables.product.prodname_github_connect %} to integrate {% data variables.product.product_name %} with {% data variables.product.prodname_ghe_cloud %}. For more information, see [AUTOTITLE](/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect).
 
-{% ifversion ghes %}
-
 > [!NOTE]
 > Before you can configure access to actions on {% data variables.product.prodname_dotcom_the_website %}, you must configure {% data variables.location.product_location %} to use {% data variables.product.prodname_actions %}. For more information, see [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server).
 
-{% endif %}
-
 {% data reusables.actions.self-hosted-runner-networking-to-dotcom %}
 
 {% data reusables.actions.enterprise-limit-actions-use %}

content/admin/monitoring-and-managing-your-instance/monitoring-your-instance/monitoring-using-snmp.md

@@ -20,7 +20,7 @@ topics:
 ---
 SNMP is a common standard for monitoring devices over a network. We strongly recommend enabling SNMP so you can monitor the health of {% data variables.location.product_location %} and know when to add more memory, storage, or processor power to the host machine.
 
-{% data variables.product.prodname_enterprise %} has a standard SNMP installation, so you can take advantage of the [many plugins](https://www.monitoring-plugins.org/doc/man/check_snmp.html) available for Nagios or for any other monitoring system.
+{% data variables.product.prodname_enterprise %} has a standard SNMP installation, so you can take advantage of the [many plugins](https://nagios-plugins.org/doc/man/check_snmp.html) available for Nagios or for any other monitoring system.
 
 ## Configuring SNMP v2c
 

content/codespaces/developing-in-a-codespace/creating-a-codespace-for-a-repository.md

@@ -42,9 +42,6 @@
 
 {% data reusables.codespaces.starting-new-project-template %} For more information, see [AUTOTITLE](/codespaces/developing-in-a-codespace/creating-a-codespace-from-a-template).
 
-> [!NOTE]
-> If you use a JetBrains IDE, you can use {% data variables.product.prodname_cli %} to create a codespace. You can then use the JetBrains Gateway application to open the codespace in a JetBrains IDE. For more information, see [AUTOTITLE](/codespaces/developing-in-a-codespace/using-github-codespaces-in-your-jetbrains-ide).
-
 If you create a codespace from a repository, the codespace will be associated with a specific branch, which cannot be empty. You can create more than one codespace per repository or even per branch.
 
 {% data reusables.codespaces.you-can-see-all-your-codespaces %}
@@ -75,7 +72,7 @@
 {% data reusables.repositories.navigate-to-repo %}
 1. Under the repository name, select the branch dropdown menu, which is labeled with the name of the current branch, then click the branch you want to create a codespace for.
 
    ![Screenshot of the expanded branch dropdown menu, listing various branches. The dropdown menu, labeled with a branch icon and "trunk," is highlighted with a dark orange outline.](/assets/images/help/codespaces/branch-drop-down.png)
 
 1. Click the **{% octicon "code" aria-hidden="true" %} Code** button, then click the **Codespaces** tab.
 

content/codespaces/developing-in-a-codespace/deleting-a-codespace.md

@@ -28,7 +28,7 @@ You can manually delete a codespace in a variety of ways:
 Use the tabs at the top of this article to display instructions for each of these ways of deleting a codespace.
 
 > [!NOTE]
-> You can't delete a codespace from within the JetBrains Gateway, or the JetBrains client application, or from within JupyterLab.
+> You can't delete a codespace from within JupyterLab.
 
 ## Why you should delete unused codespaces
 

content/codespaces/developing-in-a-codespace/developing-in-a-codespace.md

@@ -1,6 +1,6 @@
 ---
 title: Developing in a codespace
-intro: 'You can work in a codespace using your browser, {% data variables.product.prodname_vscode %}, a JetBrains IDE, or in a command shell.'
+intro: 'You can work in a codespace using your browser, {% data variables.product.prodname_vscode %}, or in a command shell.'
 redirect_from:
   - /github/developing-online-with-github-codespaces/developing-in-a-codespace
   - /github/developing-online-with-codespaces/developing-in-a-codespace
@@ -16,12 +16,6 @@ topics:
 shortTitle: Develop in a codespace
 ---
 
-{% jetbrains_beta %}
-
-{% data reusables.codespaces.codespaces-jetbrains-beta-note %}
-
-{% endjetbrains_beta %}
-
 ## About development with {% data variables.product.prodname_github_codespaces %}
 
 {% ifversion ghec %}
@@ -33,7 +27,6 @@ shortTitle: Develop in a codespace
 You can develop code in a codespace using your choice of tool:
 
 * A command shell, via an SSH connection initiated using {% data variables.product.prodname_cli %}
-* One of the JetBrains IDEs, via the JetBrains Gateway
 * The {% data variables.product.prodname_vscode %} desktop application
 * A browser-based version of {% data variables.product.prodname_vscode %}
 
@@ -76,60 +69,6 @@ For troubleshooting information, see [AUTOTITLE](/codespaces/troubleshooting/tro
 
 {% endvscode %}
 
-{% jetbrains_beta %}
-
-The tabs in this article allow you to switch between information for each of these ways of working. You're currently on the tab for JetBrains IDEs.
-
-## Working in a codespace in a JetBrains IDE
-
-To use {% data variables.product.prodname_github_codespaces %} with a JetBrains IDE you must have already installed JetBrains Gateway. For information about installing JetBrains Gateway, see [the JetBrains website](https://www.jetbrains.com/remote-development/gateway/).
-
-You can work in a codespace using your choice of JetBrains IDE. After creating a codespace, you can use the JetBrains Gateway application to open the codespace in your preferred IDE.
-
-You can edit code, debug, and use Git commands while developing in a codespace with your JetBrains IDE. For more information about the various JetBrains IDEs, see the [JetBrains documentation](https://www.jetbrains.com/help/).
-
-### IntelliJ IDEA user interface
-
-Within the {% data variables.product.prodname_github_codespaces %} documentation we use IntelliJ IDEA as a representative JetBrains IDE. Different JetBrains IDEs may have different layouts.
-
-![Annotated screenshot of the six main components of the user interface for JetBrains IntelliJ IDEA.](/assets/images/help/codespaces/jetbrains-gui-with-callouts.png)
-
-The main components of the user interface are:
-
-1. **Navigation bar** - This displays the path to the currently selected file or directory. Use the buttons to the right of the navigation bar to perform various actions, including building, running, or debugging the project, or running Git commands to commit and push your changes.
-1. **Project tool window** - This shows you the structure of your project and allows you to open files in the editor.
-1. **{% data variables.product.prodname_github_codespaces %} tool window** - This is displayed by clicking the {% data variables.product.prodname_github_codespaces %} plugin in the bar to the left of the tool window. It displays information about your codespace, including its display name and machine type. The buttons at the top of this tool window allow you to:
-   * Refresh the details in the tool window for the active codespace
-   * Display the "Your codespaces" web page
-   * View the codespace creation logs
-1. **Editor** - This is where you edit your files. You can right-click the tab for a file to access options such as moving the tab to a new window.
-1. **Terminal** - This is displayed by clicking **Terminal** in the tool window bar at the bottom of the main window (just above the status bar). The integrated terminal allows you to perform command-line tasks without having to switch to a dedicated terminal application.
-1. **Status bar** - Hover over the icon at the left of the status bar to see a list of tools. Click the icon to hide or show the tool window bars. The right side of the status bar shows information about the project, including the current Git branch.
-
-For more information about the IntelliJ IDEA user interface, see the [JetBrains documentation for IntelliJ IDEA](https://www.jetbrains.com/help/idea/guided-tour-around-the-user-interface.html).
-
-### Customizing the codespaces for a repository
-
-You can customize the codespaces that are created for a repository by creating or updating the dev container configuration for the repository. You can do this from within a codespace. After you change a dev container configuration, you can apply the changes to the current codespace by rebuilding the Docker container for the codespace. For more information, see [AUTOTITLE](/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers).
-
-### Personalizing your codespace
-
-You can use a [dotfiles](https://dotfiles.github.io/tutorials/) repository to personalize aspects of the codespace environment for any codespace that you create. For more information, see [AUTOTITLE](/codespaces/setting-your-user-preferences/personalizing-github-codespaces-for-your-account#dotfiles).
-
-### Committing your changes
-
-Once you've made changes to your codespace, either new code or configuration changes, you'll want to commit and push your changes. Pushing changes to a repository ensures that anyone else who creates a codespace from this repository has the same configuration. This also means that any customization you do, to modify the configuration of codespaces created for a repository, will be available to everybody who uses the repository.
-
-For more information, see [AUTOTITLE](/codespaces/developing-in-a-codespace/using-source-control-in-your-codespace#committing-your-changes).
-
-## Further reading
-
-* [AUTOTITLE](/codespaces/developing-in-a-codespace/using-github-codespaces-in-your-jetbrains-ide)
-* [AUTOTITLE](/codespaces/reference/using-the-github-codespaces-plugin-for-jetbrains)
-* [AUTOTITLE](/codespaces/troubleshooting/troubleshooting-github-codespaces-clients)
-
-{% endjetbrains_beta %}
-
 {% cli %}
 
 The tabs in this article allow you to switch between information for each of these ways of working. You're currently on the tab for {% data variables.product.prodname_cli %}.