diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md index f3be54b66527..6e51c2f69e23 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners.md @@ -28,12 +28,8 @@ For information on supported operating systems for self-hosted runners, or using You can set up automation to scale the number of self-hosted runners. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners). -{% ifversion actions-single-use-tokens %} - You can register ephemeral runners that perform a single job before the registration is cleaned up by using just-in-time runner registration. For more information, see [AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#using-just-in-time-runners). -{% endif %} - ## Prerequisites {% data reusables.actions.self-hosted-runners-prerequisites %} diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners.md index 930cb48970da..c76382f66238 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners.md @@ -48,12 +48,8 @@ The {% data variables.product.prodname_actions %} service will then automaticall > [!NOTE] > If a job is labeled for a certain type of runner, but none matching that type are available, the job does not immediately fail at the time of queueing. Instead, the job will remain queued until the 24 hour timeout period expires. -{% ifversion actions-single-use-tokens %} - Alternatively, you can create ephemeral, just-in-time runners using the REST API. For more information, see [AUTOTITLE](/rest/actions/self-hosted-runners). -{% endif %} - ## Controlling runner software updates on self-hosted runners By default, self-hosted runners will automatically perform a software update whenever a new version of the runner software is available. If you use ephemeral runners in containers then this can lead to repeated software updates when a new runner version is released. Turning off automatic updates allows you to update the runner version on the container image directly on your own schedule. diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/removing-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/removing-self-hosted-runners.md index 3bac1dee60cb..cb1f3454ceef 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/removing-self-hosted-runners.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/removing-self-hosted-runners.md @@ -20,9 +20,7 @@ shortTitle: Remove self-hosted runners > [!NOTE] > * {% data reusables.actions.self-hosted-runner-removal-impact %} > * {% data reusables.actions.self-hosted-runner-auto-removal %} -{%- ifversion actions-single-use-tokens %} > * {% data reusables.actions.jit-runner-removal %} -{%- endif %} To remove a self-hosted runner from a user repository you must be the repository owner. Organization owners{% ifversion custom-org-roles %} and users with the "Manage organization runners and runner groups" permission{% endif %} can remove a runner from a repository in the organization. {% ifversion custom-org-roles %}For more information about custom organization roles, see [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles).{% endif %} @@ -42,9 +40,7 @@ For information about how to remove a self-hosted runner with the REST API, see > [!NOTE] > * {% data reusables.actions.self-hosted-runner-removal-impact %} > * {% data reusables.actions.self-hosted-runner-auto-removal %} -{%- ifversion actions-single-use-tokens %} > * {% data reusables.actions.jit-runner-removal %} -{%- endif %} To remove a self-hosted runner from an organization, you must be an organization owner{% ifversion custom-org-roles %} or have the "Manage organization runners and runner groups" permission{% endif %}. We recommend that you also have access to the self-hosted runner machine. For information about how to remove a self-hosted runner with the REST API, see [AUTOTITLE](/rest/actions/self-hosted-runners). @@ -67,11 +63,8 @@ If you use {% data variables.product.prodname_ghe_cloud %}, you can also remove > [!NOTE] > * {% data reusables.actions.self-hosted-runner-removal-impact %} > * {% data reusables.actions.self-hosted-runner-auto-removal %} -{%- ifversion actions-single-use-tokens %} > * {% data reusables.actions.jit-runner-removal %} -{%- endif %} - To remove a self-hosted runner from an enterprise, you must be an enterprise owner. We recommend that you also have access to the self-hosted runner machine. For information about how to remove a self-hosted runner with the REST API, see the enterprise endpoints in the [{% data variables.product.prodname_actions %} REST API](/rest/actions/self-hosted-runners). {% data reusables.actions.self-hosted-runner-reusing %} diff --git a/content/actions/security-for-github-actions/security-guides/automatic-token-authentication.md b/content/actions/security-for-github-actions/security-guides/automatic-token-authentication.md index bc72270705d4..0f105441a286 100644 --- a/content/actions/security-for-github-actions/security-guides/automatic-token-authentication.md +++ b/content/actions/security-for-github-actions/security-guides/automatic-token-authentication.md @@ -92,7 +92,7 @@ The following table shows the permissions granted to the `GITHUB_TOKEN` by defau | {% endif %} | | issues | read/write | none | read | | metadata | read | read | read | -| packages | read/write | {% ifversion actions-default-workflow-permissions-restrictive %}read{% else %}none{% endif %} | read | +| packages | read/write | read | read | | pages | read/write | none | read | | pull-requests | read/write | none | read | | repository-projects | read/write | none | read | diff --git a/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md b/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md index 72baa66deb2e..75be3eb699f8 100644 --- a/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md +++ b/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md @@ -352,8 +352,6 @@ You should also consider the environment of the self-hosted runner machines: Some customers might attempt to partially mitigate these risks by implementing systems that automatically destroy the self-hosted runner after each job execution. However, this approach might not be as effective as intended, as there is no way to guarantee that a self-hosted runner only runs one job. Some jobs will use secrets as command-line arguments which can be seen by another job running on the same runner, such as `ps x -w`. This can lead to secret leakages. -{% ifversion actions-single-use-tokens %} - ### Using just-in-time runners To improve runner registration security, you can use the REST API to create ephemeral, just-in-time (JIT) runners. These self-hosted runners perform at most one job before being automatically removed from the repository, organization, or enterprise. For more information about configuring JIT runners, see [AUTOTITLE](/rest/actions/self-hosted-runners#create-configuration-for-a-just-in-time-runner-for-an-organization). @@ -367,8 +365,6 @@ Once you have the config file from the REST API response, you can pass it to the ./run.sh --jitconfig ${encoded_jit_config} ``` -{% endif %} - ### Planning your management strategy for self-hosted runners A self-hosted runner can be added to various levels in your {% data variables.product.prodname_dotcom %} hierarchy: the enterprise, organization, or repository level. This placement determines who will be able to manage the runner: diff --git a/content/actions/sharing-automations/required-workflows.md b/content/actions/sharing-automations/required-workflows.md index c443c5dbbc76..b8580826f40e 100644 --- a/content/actions/sharing-automations/required-workflows.md +++ b/content/actions/sharing-automations/required-workflows.md @@ -16,7 +16,7 @@ redirect_from: ## Overview -You can configure a workflow that must run in repositories in an organization for all pull requests opened against {% ifversion actions-required-workflow-improvements %}any target branch{% else %}the default branch{% endif %}. Required workflows allow you to implement organization-wide CI/CD policies that apply to current and future repositories. A required workflow is triggered by {% ifversion actions-required-workflow-improvements %}`pull_request` and `pull_request_target` default events{% else %}pull request events{% endif %} and appears as a required status check, which blocks the ability to merge the pull request until the required workflow succeeds. +You can configure a workflow that must run in repositories in an organization for all pull requests opened against any target branch. Required workflows allow you to implement organization-wide CI/CD policies that apply to current and future repositories. A required workflow is triggered by `pull_request` and `pull_request_target` default events and appears as a required status check, which blocks the ability to merge the pull request until the required workflow succeeds. Required workflows are not the same as reusable workflows. Reusable workflows can be called by another workflow. Required workflows are enforced on repositories by an organization owner. diff --git a/content/actions/sharing-automations/reusing-workflows.md b/content/actions/sharing-automations/reusing-workflows.md index 6832eb80beef..ed96fc35f5ef 100644 --- a/content/actions/sharing-automations/reusing-workflows.md +++ b/content/actions/sharing-automations/reusing-workflows.md @@ -104,7 +104,6 @@ Called workflows that are owned by the same user or organization{% ifversion ghe * You can call a maximum of 20 unique reusable workflows from a single workflow file. {% endif %} {% ifversion private-actions %}{% else %}- Reusable workflows stored within a private repository can only be used by workflows within the same repository.{% endif %} -{% ifversion actions-reusable-workflow-matrix %}{% else %}* The `strategy` property is not supported in any job that calls a reusable workflow.{% endif %} * Any environment variables set in an `env` context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/learn-github-actions/contexts#env-context). * Similarly, environment variables set in the `env` context, defined in the called workflow, are not accessible in the `env` context of the caller workflow. Instead, you must use outputs of the reusable workflow. For more information, see [Using outputs from a reusable workflow](#using-outputs-from-a-reusable-workflow). * To reuse variables in multiple workflows, set them at the organization, repository, or environment levels and reference them using the `vars` context. For more information see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/learn-github-actions/contexts#vars-context). @@ -142,16 +141,11 @@ You can define inputs and secrets, which can be passed from the caller workflow {% endraw %} For details of the syntax for defining inputs and secrets, see [`on.workflow_call.inputs`](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callinputs) and [`on.workflow_call.secrets`](/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets). - {% ifversion actions-inherit-secrets-reusable-workflows %} 1. In the reusable workflow, reference the input or secret that you defined in the `on` key in the previous step. > [!NOTE] > If the secrets are inherited by using `secrets: inherit` in the calling workflow, you can reference them even if they are not explicitly defined in the `on` key. For more information, see [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretsinherit). - {%- else %} -1. In the reusable workflow, reference the input or secret that you defined in the `on` key in the previous step. - {%- endif %} - {% raw %} ```yaml @@ -225,8 +219,6 @@ You can call multiple workflows, referencing each in a separate job. {% data reusables.actions.pass-inputs-to-reusable-workflows %} -{% ifversion actions-reusable-workflow-matrix %} - ### Using a matrix strategy with a reusable workflow Jobs using the matrix strategy can call a reusable workflow. @@ -249,7 +241,6 @@ jobs: ``` {% endraw %} -{% endif %} ### Supported keywords for jobs that call a reusable workflow @@ -261,12 +252,8 @@ When you call a reusable workflow, you can only use the following keywords in th * [`jobs..with.`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idwithinput_id) * [`jobs..secrets`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecrets) * [`jobs..secrets.`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretssecret_id) -{%- ifversion actions-inherit-secrets-reusable-workflows %} * [`jobs..secrets.inherit`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsecretsinherit) -{%- endif %} -{%- ifversion actions-reusable-workflow-matrix %} * [`jobs..strategy`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy) -{%- endif %} * [`jobs..needs`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds) * [`jobs..if`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif) * [`jobs..concurrency`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency) @@ -368,10 +355,10 @@ For information on how to use the API to determine which workflow files were inv ## Using outputs from a reusable workflow -A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow.{% ifversion actions-reusable-workflow-matrix %} +A reusable workflow may generate data that you want to use in the caller workflow. To use these outputs, you must specify them as the outputs of the reusable workflow. If a reusable workflow that sets an output is executed with a matrix strategy, the output will be the output set by the last successful completing reusable workflow of the matrix which actually sets a value. -That means if the last successful completing reusable workflow sets an empty string for its output, and the second last successful completing reusable workflow sets an actual value for its output, the output will contain the value of the second last completing reusable workflow.{% endif %} +That means if the last successful completing reusable workflow sets an empty string for its output, and the second last successful completing reusable workflow sets an actual value for its output, the output will contain the value of the second last completing reusable workflow. The following reusable workflow has a single job containing two steps. In each of these steps we set a single word as the output: "hello" and "world." In the `outputs` section of the job, we map these step outputs to job outputs called: `output1` and `output2`. In the `on.workflow_call.outputs` section we then define two outputs for the workflow itself, one called `firstword` which we map to `output1`, and one called `secondword` which we map to `output2`. diff --git a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md index 60b99176a879..031d0655569c 100644 --- a/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md +++ b/content/actions/use-cases-and-examples/building-and-testing/building-and-testing-go.md @@ -148,9 +148,8 @@ You can use `go get` to install dependencies: ### Caching dependencies -You can cache and restore dependencies using the [`setup-go` action](https://github.com/actions/setup-go). By default, caching is {% ifversion actions-setup-go-default-cache-enabled %}enabled when using the `setup-go` action.{% else %}disabled, but you can set the `cache` parameter to `true` to enable it.{% endif %} +You can cache and restore dependencies using the [`setup-go` action](https://github.com/actions/setup-go). By default, caching is enabled when using the `setup-go` action. -{% ifversion actions-setup-go-default-cache-enabled %} The `setup-go` action searches for the dependency file, `go.sum`, in the repository root and uses the hash of the dependency file as a part of the cache key. You can use the `cache-dependency-path` parameter for cases when multiple dependency files are used, or when they are located in different subdirectories. @@ -163,30 +162,6 @@ You can use the `cache-dependency-path` parameter for cases when multiple depend cache-dependency-path: subdir/go.sum ``` -{% else %} - -When caching is enabled, the `setup-go` action searches for the dependency file, `go.sum`, in the repository root and uses the hash of the dependency file as a part of the cache key. - -```yaml copy - - name: Setup Go - uses: {% data reusables.actions.action-setup-go %} - with: - go-version: '1.21.x' - cache: true -``` - -Alternatively, you can use the `cache-dependency-path` parameter for cases when multiple dependency files are used, or when they are located in different subdirectories. - -```yaml copy - - uses: {% data reusables.actions.action-setup-go %} - with: - go-version: '1.17' - cache: true - cache-dependency-path: subdir/go.sum -``` - -{% endif %} - If you have a custom requirement or need finer controls for caching, you can use the [`cache` action](https://github.com/marketplace/actions/cache). For more information, see [AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows). ## Building and testing your code diff --git a/content/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-google-cloud-storage.md b/content/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-google-cloud-storage.md index 83baa2a51626..f5f216e5f733 100644 --- a/content/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-google-cloud-storage.md +++ b/content/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-google-cloud-storage.md @@ -3,7 +3,7 @@ title: Enabling GitHub Actions with Google Cloud Storage intro: 'You can enable {% data variables.product.prodname_actions %} on {% data variables.product.prodname_ghe_server %} and use Google Cloud Storage to store data generated by workflow runs.' permissions: 'Site administrators can enable {% data variables.product.prodname_actions %} and configure enterprise settings.' versions: - feature: actions-ghes-gcp-storage + ghes: '*' type: how_to topics: - Actions diff --git a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md index 8ed1ef4af57b..af706adcf3e7 100644 --- a/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md +++ b/content/admin/managing-github-actions-for-your-enterprise/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server.md @@ -79,9 +79,7 @@ All other {% data variables.product.prodname_actions %} data, such as the workfl * Azure Blob storage * Amazon S3 -{%- ifversion actions-ghes-gcp-storage %} * Google Cloud Storage -{%- endif %} * S3-compatible MinIO cluster > [!NOTE] @@ -101,9 +99,7 @@ Follow one of the procedures below to enable {% data variables.product.prodname_ * [Enabling GitHub Actions with Azure Blob storage](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage) * [Enabling GitHub Actions with Amazon S3 storage](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-amazon-s3-storage) -{%- ifversion actions-ghes-gcp-storage %} * [Enabling GitHub Actions with Google Cloud Storage](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-google-cloud-storage) -{%- endif %} * [Enabling GitHub Actions with MinIO storage](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-minio-storage) ## Managing access permissions for {% data variables.product.prodname_actions %} in your enterprise diff --git a/content/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics.md b/content/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics.md index a7dc76479802..d1eb5920d41c 100644 --- a/content/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics.md +++ b/content/admin/monitoring-activity-in-your-enterprise/analyzing-how-your-team-works-with-server-statistics/about-server-statistics.md @@ -96,7 +96,6 @@ The following aggregate metrics will be collected and transmitted on a daily bas | AN | `ghe_stats.users.total_users` | Number of user accounts | | AO | `ghe_stats.users.admin_users` | Number of user accounts that are site administrators | | AP | `ghe_stats.users.suspended_users` | Number of user accounts that are suspended | -| {% ifversion actions-server-statistics %} | | AQ | `actions_stats.number_of_repos_using_actions` | Number of repositories using {% data variables.product.prodname_actions %} | | AR | `actions_stats.percentage_of_repos_using_actions` | Percentage of repositories using {% data variables.product.prodname_actions %} | | AS | `packages_stats.registry_enabled` | Whether {% data variables.product.prodname_registry %} with repository-scoped packages is enabled for {% data variables.location.product_location %} | @@ -167,7 +166,6 @@ The following aggregate metrics will be collected and transmitted on a daily bas | DF |`packages_stats.ecosystems.containers.daily_update_count` | Number of container images updated | | DG |`packages_stats.ecosystems.containers.daily_delete_count` | Number of container images deleted | | DH | `packages_stats.ecosystems.containers.daily_create_count` | Number of container images created | -| {% endif %} | ## {% data variables.product.prodname_server_statistics %} data examples diff --git a/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md b/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md index 603904feb051..d29dc52582e6 100644 --- a/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md +++ b/content/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization.md @@ -98,7 +98,7 @@ You can configure this behavior for an organization using the procedure below. M {% data reusables.actions.workflows.required-workflow-beta %} -You can configure required workflows to run in all or selected repositories in an organization where you are an owner. Required workflows are triggered by {% ifversion actions-required-workflow-improvements %}`pull_request` and `pull_request_target` default events{% else %}pull requests{% endif %} and must pass before a pull request can be merged. For more information, see [AUTOTITLE](/actions/using-workflows/required-workflows). +You can configure required workflows to run in all or selected repositories in an organization where you are an owner. Required workflows are triggered by `pull_request` and `pull_request_target` default events and must pass before a pull request can be merged. For more information, see [AUTOTITLE](/actions/using-workflows/required-workflows). ### Prerequisites @@ -125,7 +125,7 @@ Note the following restrictions and behaviors for the target repositories: {% data reusables.organizations.settings-sidebar-actions-general %} 1. To the right of "Required Workflows", click **Add workflow**. -1. Under "Required workflow", use the drop-down menu to select the repository that contains the workflow. Then, enter the path to the workflow in the text field. {% ifversion actions-required-workflow-improvements %}You can reference any branch, tag, or commit SHA from the repository containing the workflow file using the `{path}@{ref}` syntax.{% endif %} +1. Under "Required workflow", use the drop-down menu to select the repository that contains the workflow. Then, enter the path to the workflow in the text field. You can reference any branch, tag, or commit SHA from the repository containing the workflow file using the `{path}@{ref}` syntax. 1. Under "Apply to repositories...", use the drop-down menu to select which repositories the required workflow applies to. Select **All repositories** to apply the required workflow to all repositories in your organization, or **Selected repositories** to choose which repositories it will apply to. @@ -160,9 +160,7 @@ You can set the default permissions for the `GITHUB_TOKEN` in the settings for y ### Configuring the default `GITHUB_TOKEN` permissions -{% ifversion actions-default-workflow-permissions-restrictive %} By default, when you create a new organization,{% ifversion ghec or ghes %} the setting is inherited from what is configured in the enterprise settings.{% else %} `GITHUB_TOKEN` only has read access for the `contents` and `packages` scopes.{% endif %} -{% endif %} {% data reusables.profile.access_profile %} {% data reusables.profile.access_org %} diff --git a/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository.md b/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository.md index e731911e9310..b112f5929900 100644 --- a/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository.md +++ b/content/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository.md @@ -91,9 +91,7 @@ The default permissions can also be configured in the organization settings. If ### Configuring the default `GITHUB_TOKEN` permissions -{% ifversion actions-default-workflow-permissions-restrictive %} By default, when you create a new repository in your personal account, `GITHUB_TOKEN` only has read access for the `contents` and `packages` scopes. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings. -{% endif %} {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.sidebar-settings %} @@ -105,9 +103,7 @@ By default, when you create a new repository in your personal account, `GITHUB_T {% data reusables.actions.workflow-pr-approval-permissions-intro %} -{% ifversion actions-default-workflow-permissions-restrictive %} By default, when you create a new repository in your personal account, workflows are not allowed to create or approve pull requests. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings. -{% endif %} {% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.sidebar-settings %} diff --git a/data/reusables/actions/action-setup-go.md b/data/reusables/actions/action-setup-go.md index 4f051db1e7f2..8c1318dbfc6b 100644 --- a/data/reusables/actions/action-setup-go.md +++ b/data/reusables/actions/action-setup-go.md @@ -1 +1 @@ -actions/setup-go@{% ifversion actions-setup-go-default-cache-enabled %}v5{% else %}v3{% endif %} +actions/setup-go@v5 diff --git a/data/reusables/actions/configure-storage-provider-platform-commands.md b/data/reusables/actions/configure-storage-provider-platform-commands.md index 5799a22b88cc..e04285571957 100644 --- a/data/reusables/actions/configure-storage-provider-platform-commands.md +++ b/data/reusables/actions/configure-storage-provider-platform-commands.md @@ -10,11 +10,8 @@ ghe-config secrets.actions.storage.blob-provider "s3" ``` -{%- ifversion actions-ghes-gcp-storage %} * Google Cloud Storage: - + ```shell copy ghe-config secrets.actions.storage.blob-provider "gcs" ``` - -{%- endif %} diff --git a/data/reusables/actions/configure-storage-provider.md b/data/reusables/actions/configure-storage-provider.md index 09a86c93735a..3adf422c12c8 100644 --- a/data/reusables/actions/configure-storage-provider.md +++ b/data/reusables/actions/configure-storage-provider.md @@ -21,7 +21,6 @@ ghe-config secrets.actions.storage.s3.force-path-style true ``` -{%- ifversion actions-ghes-gcp-storage %} * Google Cloud Storage: ```shell copy @@ -30,5 +29,3 @@ ghe-config secrets.actions.storage.gcs.access-key-id "HMAC ACCESS ID" ghe-config secrets.actions.storage.gcs.access-secret "HMAC SECRET" ``` - -{%- endif %} diff --git a/data/reusables/actions/enterprise-storage-ha-backups.md b/data/reusables/actions/enterprise-storage-ha-backups.md index 1fc6cd0c6e32..7dcba0f0dde8 100644 --- a/data/reusables/actions/enterprise-storage-ha-backups.md +++ b/data/reusables/actions/enterprise-storage-ha-backups.md @@ -1 +1 @@ -{% data variables.product.prodname_actions %} uses external storage to store workflow artifacts and logs. This data is stored on your external provider, such as Azure blob storage, Amazon S3,{% ifversion actions-ghes-gcp-storage %} Google Cloud Storage,{% endif %} or MinIO. As a result, {% data variables.product.prodname_ghe_server %} backups and {% data variables.product.prodname_ghe_server %} high availability configurations do not provide protection for the data stored on this external storage, and instead rely on the data protection and replication provided by the external storage provider, such as Azure{% ifversion actions-ghes-gcp-storage %}, Google Cloud,{% endif %} or AWS. +{% data variables.product.prodname_actions %} uses external storage to store workflow artifacts and logs. This data is stored on your external provider, such as Azure blob storage, Amazon S3, Google Cloud Storage, or MinIO. As a result, {% data variables.product.prodname_ghe_server %} backups and {% data variables.product.prodname_ghe_server %} high availability configurations do not provide protection for the data stored on this external storage, and instead rely on the data protection and replication provided by the external storage provider, such as Azure, Google Cloud, or AWS. diff --git a/data/reusables/actions/pass-inputs-to-reusable-workflows.md b/data/reusables/actions/pass-inputs-to-reusable-workflows.md index d862981d9168..990bc6cc1b2b 100644 --- a/data/reusables/actions/pass-inputs-to-reusable-workflows.md +++ b/data/reusables/actions/pass-inputs-to-reusable-workflows.md @@ -14,7 +14,6 @@ jobs: {% endraw %} -{% ifversion actions-inherit-secrets-reusable-workflows %} Workflows that call reusable workflows in the same organization or enterprise can use the `inherit` keyword to implicitly pass the secrets. {% raw %} @@ -29,5 +28,3 @@ jobs: ``` {% endraw %} - -{% endif %} diff --git a/data/reusables/actions/workflows/github-token-access.md b/data/reusables/actions/workflows/github-token-access.md index e729af1ab102..7012990f4a8e 100644 --- a/data/reusables/actions/workflows/github-token-access.md +++ b/data/reusables/actions/workflows/github-token-access.md @@ -1 +1 @@ -1. Under "Workflow permissions", choose whether you want the `GITHUB_TOKEN` to have read and write access for all permissions (the permissive setting), or just read access for the `contents` {% ifversion actions-default-workflow-permissions-restrictive %}and `packages` permissions{% else %}permission{% endif %} (the restricted setting). +1. Under "Workflow permissions", choose whether you want the `GITHUB_TOKEN` to have read and write access for all permissions (the permissive setting), or just read access for the `contents` and `packages` permissions (the restricted setting). diff --git a/data/reusables/actions/workflows/required-workflow-prerequisites.md b/data/reusables/actions/workflows/required-workflow-prerequisites.md index d35f1ba419c3..a23a793e0c64 100644 --- a/data/reusables/actions/workflows/required-workflow-prerequisites.md +++ b/data/reusables/actions/workflows/required-workflow-prerequisites.md @@ -1,8 +1,8 @@ * {% data variables.product.prodname_actions %} must be enabled for a repository in the organization's settings in order for required workflows to run. Once enabled at an organization-level, required workflows will run even when {% data variables.product.prodname_actions %} is disabled in the repository's settings. For more information on managing {% data variables.product.prodname_actions %} in your organization's repositories, see [AUTOTITLE](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#managing-github-actions-permissions-for-your-organization). * Required workflows are available for organizations and only in repositories where the organization's plan supports required status checks. If required status checks are not supported, the workflow will still run, but it will not be a required check and will not block merging. For more information about support for required status checks, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). * The repository's default branch must match the organization's default branch setting in order for required workflows to run as required status checks. If the default branch names do not match, the workflow will still run, but it will not be a required check. For more information about managing default branch names, see [AUTOTITLE](/organizations/managing-organization-settings/managing-the-default-branch-name-for-repositories-in-your-organization) and [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch). -* For required workflows to run, the pull request's source repository must be in the same organization as the target repository. {% data variables.product.product_name %} will source the required workflow from {% ifversion actions-required-workflow-improvements %}a specified branch, tag, or commit SHA {% else %}the HEAD commit of the default branch {% endif %}from the repository containing the workflow. +* For required workflows to run, the pull request's source repository must be in the same organization as the target repository. {% data variables.product.product_name %} will source the required workflow from a specified branch, tag, or commit SHA from the repository containing the workflow. * Secrets used in a required workflow should be created at either the organization level or in the target repositories. * Secrets in the source repository will not be fetched when a workflow runs in the target repository. -{% ifversion actions-required-workflow-improvements %}* When a workflow is run as a required workflow it will ignore all the filters in the `on:` section, for example: `branches`, `branches-ignore`, `paths`, `types` etc. The required workflow will run only for the `pull_request` and `pull_request_target` default events. For more information on default activity types, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#pull_request).{% endif %} +* When a workflow is run as a required workflow it will ignore all the filters in the `on:` section, for example: `branches`, `branches-ignore`, `paths`, `types` etc. The required workflow will run only for the `pull_request` and `pull_request_target` default events. For more information on default activity types, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#pull_request). * Required workflows are not automatically triggered on already existing pull requests even though they automatically appear as expected checks. To trigger required workflows for an already existing pull request, push a new change to that pull request. diff --git a/data/reusables/actions/workflows/required-workflow-source-notes.md b/data/reusables/actions/workflows/required-workflow-source-notes.md index cf3ad2c3767a..2853e8896de6 100644 --- a/data/reusables/actions/workflows/required-workflow-source-notes.md +++ b/data/reusables/actions/workflows/required-workflow-source-notes.md @@ -2,10 +2,8 @@ * If the required workflow is contained in a private {% ifversion ghes or ghec %}or internal {% endif %}repository, you must ensure that workflows within the repository are accessible by other repositories in your organization. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#managing-access-for-a-private-repository){% ifversion ghes or ghec %} and [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-an-internal-repository){% endif %}. * Workflows stored in a public repository can be configured as required workflows for any repository in your organization. Workflows stored in a private repository can only be configured as required workflows for other private repositories in your organization. {% ifversion ghes or ghec %} Workflows stored in internal repositories can be configured as required workflows for internal and private repositories in your organization.{% endif %} * {% data variables.product.prodname_codeql %} is not supported in required workflows because {% data variables.product.prodname_codeql %} requires configuration at the repository level. For information on configuring code scanning, see [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning). -{% ifversion actions-required-workflow-improvements %} {% ifversion fpt or ghec %} * To push to a branch where required workflows are enforced at the organizational level, create a pull request to make the necessary changes. You cannot push directly to branches with required workflow enforcements. * If you want to allow direct pushes for a particular repository, you must remove the repository as a target from respective required workflows. {% endif %} * Required workflows can be referenced using any branch, tag, or commit SHA from the repository containing the workflow file. -{% endif %}