Repo sync

content/actions/concepts/security/index.md

@@ -12,5 +12,6 @@ children:
   - /openid-connect
   - /script-injections
   - /compromised-runners
+  - /kubernetes-admissions-controller
 ---
 

content/actions/concepts/security/kubernetes-admissions-controller.md

@@ -0,0 +1,33 @@
+---
+title: Kubernetes admissions controller
+intro: Understand how you can use an admissions controller to enforce artifact attestations in your Kubernetes cluster.
+versions:
+  fpt: '*'
+  ghec: '*'
+---
+
+## 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.
+
+Kubernetes admission controllers are plugins that govern the behavior of the Kubernetes API server. They are commonly used to enforce security policies and best practices in a Kubernetes cluster.
+
+Using the open source [Sigstore Policy Controller](https://docs.sigstore.dev/policy-controller/overview/) project you can add an admission controller to your Kubernetes cluster that can enforce artifact attestations. This way, you can ensure that only artifacts with valid attestations can be deployed.
+
+To [install the controller](/actions/how-tos/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-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.
+
+A `TrustRoot` may also contain a [TUF](https://theupdateframework.io/) repository root, making it possible for your cluster to continuously and securely receive updates to its trusted public key material. If left unspecified, a `ClusterImagePolicy` will by default use the open source Sigstore Public Good Instance's key material. When verifying attestations generated for private repositories, the `ClusterImagePolicy` must reference the GitHub `TrustRoot`.
+
+## Next steps
+
+When you're ready to use an admission controller, see [AUTOTITLE](/actions/how-tos/security-for-github-actions/using-artifact-attestations/enforcing-artifact-attestations-with-a-kubernetes-admission-controller).

content/actions/get-started/understanding-github-actions.md

@@ -78,7 +78,11 @@ For more information, see [AUTOTITLE](/actions/using-jobs).
 
 ### Actions
 
-An **action** is a custom application for the {% data variables.product.prodname_actions %} platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your **workflow** files. An action can pull your Git repository from {% data variables.product.prodname_dotcom %}, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.
+An **action** is a pre-defined, reusable set of jobs or code that performs specific tasks within a **workflow**, reducing the amount of repetitive code you write in your workflow files. Actions can perform tasks such as:
+
+* Pulling your Git repository from {% data variables.product.prodname_dotcom %}
+* Setting up the correct toolchain for your build environment
+* Setting up authentication to your cloud provider
 
 You can write your own actions, or you can find actions to use in your workflows in the {% data variables.product.prodname_marketplace %}.
 

content/actions/how-tos/administering-github-actions/making-retired-namespaces-available-on-ghecom.md

@@ -10,7 +10,7 @@ redirect_from:
   - /actions/administering-github-actions/making-retired-namespaces-available-on-ghecom
 ---
 
-## About retirement of namespaces
+## Overview
 
 If you use {% data variables.enterprise.data_residency %}, members of your enterprise can create {% data variables.product.prodname_actions %} workflows that use actions directly from {% data variables.product.prodname_dotcom_the_website %} or [{% data variables.product.prodname_marketplace %}](https://github.com/marketplace?type=actions).
 

content/actions/how-tos/index.md

@@ -15,7 +15,6 @@ children:
   - /managing-self-hosted-runners
   - /using-larger-runners
   - /security-for-github-actions
-  - /use-cases-and-examples
   - /administering-github-actions
   - /monitor-workflows
   - /troubleshooting-workflows

content/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow.md

@@ -1,20 +1,17 @@
 ---
 title: Canceling a workflow
 shortTitle: Cancel a workflow
-intro: 'You can cancel a workflow run that is in progress. When you cancel a workflow run, {% data variables.product.prodname_dotcom %} cancels all jobs and steps that are a part of that workflow.'
+intro: 'You can cancel a workflow run, including all jobs and steps, that is in progress.'
 versions:
   fpt: '*'
   ghes: '*'
   ghec: '*'
+permissions: '{% data reusables.repositories.permissions-statement-write %}'
 redirect_from:
   - /actions/managing-workflow-runs/canceling-a-workflow
   - /actions/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow
 ---
 
-{% data reusables.actions.enterprise-github-hosted-runners %}
-
-{% data reusables.repositories.permissions-statement-write %}
-
 ## Canceling a workflow run
 
 {% data reusables.repositories.navigate-to-repo %}
@@ -24,12 +21,6 @@ redirect_from:
 1. In the upper-right corner of the workflow, click **Cancel workflow**.
 ![Screenshot showing the summary for a workflow that is currently running. The "Cancel workflow" button is highlighted with a dark orange outline.](/assets/images/help/repository/cancel-check-suite-updated.png)
 
-## Steps {% data variables.product.prodname_dotcom %} takes to cancel a workflow run
-
-When canceling workflow run, you may be running other software that uses resources that are related to the workflow run. To help you free up resources related to the workflow run, it may help to understand the steps {% data variables.product.prodname_dotcom %} performs to cancel a workflow run.
+## Next steps
 
-1. To cancel the workflow run, the server re-evaluates `if` conditions for all currently running jobs. If the condition evaluates to `true`, the job will not get canceled. For example, the condition `if: always()` would evaluate to true and the job continues to run. When there is no condition, that is the equivalent of the condition `if: success()`, which only runs if the previous step finished successfully.
-1. For jobs that need to be canceled, the server sends a cancellation message to all the runner machines with jobs that need to be canceled.
-1. For jobs that continue to run, the server re-evaluates `if` conditions for the unfinished steps. If the condition evaluates to `true`, the step continues to run. You can use the `cancelled` expression to apply a status check of `cancelled()`. For more information see [AUTOTITLE](/actions/learn-github-actions/expressions#cancelled).
-1. For steps that need to be canceled, the runner machine sends `SIGINT/Ctrl-C` to the step's entry process (`node` for javascript action, `docker` for container action, and `bash/cmd/pwd` when using `run` in a step). If the process doesn't exit within 7500 ms, the runner will send `SIGTERM/Ctrl-Break` to the process, then wait for 2500 ms for the process to exit. If the process is still running, the runner kills the process tree.
-1. After the 5 minutes cancellation timeout period, the server will force terminate all jobs and steps that don't finish running or fail to complete the cancellation process.
+To learn about the process {% data variables.product.prodname_dotcom %} uses to cancel a workflow run, as well as the ways you can free up related resources, see [AUTOTITLE](/actions/reference/workflow-cancellation-reference).

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

@@ -12,28 +12,6 @@ redirect_from:
 
 >[!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.
-
-Kubernetes admission controllers are plugins that govern the behavior of the Kubernetes API server. They are commonly used to enforce security policies and best practices in a Kubernetes cluster.
-
-Using the open source [Sigstore Policy Controller](https://docs.sigstore.dev/policy-controller/overview/) project you can add an admission controller to your Kubernetes cluster that can enforce artifact attestations. This way, you can ensure that only artifacts with valid attestations can be deployed.
-
-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.
-
-A `TrustRoot` may also contain a [TUF](https://theupdateframework.io/) repository root, making it possible for your cluster to continuously and securely receive updates to its trusted public key material. If left unspecified, a `ClusterImagePolicy` will by default use the open source Sigstore Public Good Instance's key material. When verifying attestations generated for private repositories, the `ClusterImagePolicy` must reference the GitHub `TrustRoot`.
-
 ## Getting started with Kubernetes admission controller
 
 To set up an admission controller for enforcing GitHub artifact attestations, you need to:

content/actions/how-tos/sharing-automations/sharing-actions-and-workflows-from-your-private-repository.md

@@ -3,31 +3,28 @@ title: Sharing actions and workflows from your private repository
 intro: You can share an action or reusable workflow without publishing them publicly.
 versions:
   fpt: '*'
-type: tutorial
 topics:
   - Actions
   - Action development
-shortTitle: Share from your private repository
+shortTitle: Share across private repositories
 redirect_from:
   - /actions/creating-actions/sharing-actions-and-workflows-from-your-private-repository
   - /actions/sharing-automations/sharing-actions-and-workflows-from-your-private-repository
 ---
 
-## About {% data variables.product.prodname_actions %} access to private repositories
-
-You can share actions and reusable workflows from your private repository, without making them public, by allowing {% data variables.product.prodname_actions %} workflows to access a private repository that contains the action or reusable workflow.
-
-Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private repositories owned by the same organization or user. Actions and reusable workflows stored in private repositories cannot be used in public repositories.
-
 > [!WARNING]
-> * If you make a private repository accessible to {% data variables.product.prodname_actions %} workflows in other repositories, outside collaborators on the other repositories can indirectly access the private repository, even though they do not have direct access to these repositories. The outside collaborators can view logs for workflow runs when actions or workflows from the private repository are used.
+> * {% data reusables.actions.outside-collaborators-actions %}
 > * {% data reusables.actions.scoped-token-note %}
 
 ## Sharing actions and workflows from your private repository
 
 1. Store the action or reusable workflow in a private repository. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-repository-visibility).
-1. Configure the repository to allow access to workflows in other private repositories. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).
+1. On {% data variables.product.prodname_dotcom %}, navigate to the main page of the private repository.
+1. Under your repository name, click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} Settings**.
+{% data reusables.repositories.settings-sidebar-actions-general %}
+1. To grant access to other private repositories, in the **Access** section at the bottom of the page, select **Accessible from repositories owned by 'USERNAME' user**.
+1. Click **Save** to apply the settings.
 
-## Further reading
+## Next steps
 
-* [AUTOTITLE](/actions/using-workflows/reusing-workflows)
+To reuse your shared workflows, see [AUTOTITLE](/actions/using-workflows/reusing-workflows).

content/actions/how-tos/sharing-automations/sharing-actions-and-workflows-with-your-organization.md

@@ -3,7 +3,6 @@ title: Sharing actions and workflows with your organization
 intro: You can share an action or reusable workflow with your organization without publishing the action or workflow publicly.
 versions:
   fpt: '*'
-type: tutorial
 topics:
   - Actions
   - Action development
@@ -13,21 +12,19 @@ redirect_from:
   - /actions/sharing-automations/sharing-actions-and-workflows-with-your-organization
 ---
 
-## About {% data variables.product.prodname_actions %} access to private repositories
-
-You can share actions and reusable workflows within your organization, without publishing them publicly, by allowing {% data variables.product.prodname_actions %} workflows to access a private repository that contains the action or reusable workflow.
-
-Any actions or reusable workflows stored in the private repository can be used in workflows defined in other private repositories owned by the same organization. Actions and reusable workflows stored in private repositories cannot be used in public repositories.
-
 > [!WARNING]
 > * {% data reusables.actions.outside-collaborators-actions %}
 > * {% data reusables.actions.scoped-token-note %}
 
 ## Sharing actions and workflows with your organization
 
 1. Store the action or reusable workflow in a private repository. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/about-repositories#about-repository-visibility).
-1. Configure the repository to allow access to workflows in other private repositories. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository).
+1. On {% data variables.product.prodname_dotcom %}, navigate to the main page of the private repository.
+1. Under your repository name, click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} Settings**.
+{% data reusables.repositories.settings-sidebar-actions-general %}
+1. To grant access to other private repositories in the organization, in the **Access** section at the bottom of the page, select **Accessible from repositories in the 'ORGANIZATION-NAME' organization**.
+1. Click **Save** to apply the settings.
 
-## Further reading
+## Next steps
 
-* [AUTOTITLE](/actions/using-workflows/reusing-workflows)
+To learn how to reuse your shared workflows, see [AUTOTITLE](/actions/using-workflows/reusing-workflows).