From b2acf2432b13daaf621e65b568eca07ace9f1d1a Mon Sep 17 00:00:00 2001 From: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com> Date: Fri, 17 Jan 2025 11:46:12 +0000 Subject: [PATCH] Remove product_name from actions directory (#53904) Co-authored-by: Vanessa --- ...-continuous-deployment-with-github-actions.md | 2 +- ...continuous-integration-with-github-actions.md | 6 +++--- .../understanding-github-actions.md | 4 ++-- .../about-self-hosted-runners.md | 8 ++++---- ...elf-hosted-runner-application-as-a-service.md | 4 ++-- ...ng-and-troubleshooting-self-hosted-runners.md | 8 ++++---- ...ng-a-proxy-server-with-self-hosted-runners.md | 4 ++-- .../downloading-workflow-artifacts.md | 4 ++-- .../removing-workflow-artifacts.md | 2 +- .../migrating-from-circleci-to-github-actions.md | 8 ++++---- ...grating-from-gitlab-cicd-to-github-actions.md | 2 +- ...-azure-devops-with-github-actions-importer.md | 2 +- ...g-from-bamboo-with-github-actions-importer.md | 2 +- ...ket-pipelines-with-github-actions-importer.md | 2 +- ...from-circleci-with-github-actions-importer.md | 2 +- ...g-from-gitlab-with-github-actions-importer.md | 4 ++-- ...-from-jenkins-with-github-actions-importer.md | 4 ++-- ...rom-travis-ci-with-github-actions-importer.md | 2 +- .../automatic-token-authentication.md | 2 +- .../security-hardening-for-github-actions.md | 16 ++++++++-------- .../creating-a-composite-action.md | 2 +- .../creating-a-docker-container-action.md | 2 +- .../creating-a-javascript-action.md | 4 ++-- .../developing-a-third-party-cli-action.md | 2 +- .../dockerfile-support-for-github-actions.md | 4 ++-- .../releasing-and-maintaining-actions.md | 4 ++-- .../publishing-docker-images.md | 6 +++--- .../about-github-hosted-runners.md | 6 +++--- .../store-information-in-variables.md | 2 +- .../storing-and-sharing-data-from-a-workflow.md | 6 +++--- .../events-that-trigger-workflows.md | 10 +++++----- .../triggering-a-workflow.md | 4 ++-- .../using-workflow-templates.md | 6 +++--- 33 files changed, 73 insertions(+), 73 deletions(-) diff --git a/content/actions/about-github-actions/about-continuous-deployment-with-github-actions.md b/content/actions/about-github-actions/about-continuous-deployment-with-github-actions.md index 20f8058911b9..9ab36f3a06e5 100644 --- a/content/actions/about-github-actions/about-continuous-deployment-with-github-actions.md +++ b/content/actions/about-github-actions/about-continuous-deployment-with-github-actions.md @@ -28,7 +28,7 @@ Continuous deployment is often coupled with continuous integration. For more inf You can set up a {% data variables.product.prodname_actions %} workflow to deploy your software product. To verify that your product works as expected, your workflow can build the code in your repository and run your tests before deploying. -You can configure your CD workflow to run when a {% data variables.product.product_name %} event occurs (for example, when new code is pushed to the default branch of your repository), on a set schedule, manually, or when an external event occurs using the repository dispatch webhook. For more information about when your workflow can run, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows). +You can configure your CD workflow to run when an event occurs (for example, when new code is pushed to the default branch of your repository), on a set schedule, manually, or when an external event occurs using the repository dispatch webhook. For more information about when your workflow can run, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows). {% data variables.product.prodname_actions %} provides features that give you more control over deployments. For example, you can use environments to require approval for a job to proceed, restrict which branches can trigger a workflow, or limit access to secrets. You can use concurrency to limit your CD pipeline to a maximum of one in-progress deployment and one pending deployment. For more information about these features, see [AUTOTITLE](/actions/deployment/about-deployments/deploying-with-github-actions) and [AUTOTITLE](/actions/deployment/targeting-different-environments/managing-environments-for-deployment). diff --git a/content/actions/about-github-actions/about-continuous-integration-with-github-actions.md b/content/actions/about-github-actions/about-continuous-integration-with-github-actions.md index b9703d1e018e..0c24fc3aa86e 100644 --- a/content/actions/about-github-actions/about-continuous-integration-with-github-actions.md +++ b/content/actions/about-github-actions/about-continuous-integration-with-github-actions.md @@ -35,9 +35,9 @@ Building and testing your code requires a server. You can build and test updates You can configure your CI workflow to run when a {% data variables.product.prodname_dotcom %} event occurs (for example, when new code is pushed to your repository), on a set schedule, or when an external event occurs using the repository dispatch webhook. -{% data variables.product.product_name %} runs your CI tests and provides the results of each test in the pull request, so you can see whether the change in your branch introduces an error. When all CI tests in a workflow pass, the changes you pushed are ready to be reviewed by a team member or merged. When a test fails, one of your changes may have caused the failure. +{% data variables.product.github %} runs your CI tests and provides the results of each test in the pull request, so you can see whether the change in your branch introduces an error. When all CI tests in a workflow pass, the changes you pushed are ready to be reviewed by a team member or merged. When a test fails, one of your changes may have caused the failure. -When you set up CI in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends CI workflows based on the language and framework in your repository. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.product_name %} will suggest a workflow template that installs your Node.js packages and runs your tests. You can use the CI workflow template suggested by {% data variables.product.product_name %}, customize the suggested workflow template, or create your own custom workflow file to run your CI tests. +When you set up CI in your repository, {% data variables.product.github %} analyzes the code in your repository and recommends CI workflows based on the language and framework in your repository. For example, if you use [Node.js](https://nodejs.org/en/), {% data variables.product.github %} will suggest a workflow template that installs your Node.js packages and runs your tests. You can use the CI workflow template suggested by {% data variables.product.github %}, customize the suggested workflow template, or create your own custom workflow file to run your CI tests. In addition to helping you set up CI workflows for your project, you can use {% data variables.product.prodname_actions %} to create workflows across the full software development life cycle. For example, you can use actions to deploy, package, or release your project. For more information, see [AUTOTITLE](/actions/learn-github-actions). @@ -45,7 +45,7 @@ For a definition of common terms, see [AUTOTITLE](/actions/learn-github-actions/ ## Workflow templates -{% data variables.product.product_name %} offers CI workflow templates for a variety of languages and frameworks. +{% data variables.product.github %} offers CI workflow templates for a variety of languages and frameworks. Browse the complete list of CI workflow templates offered by {% data variables.product.company_short %} in the {% ifversion fpt or ghec %}[actions/starter-workflows](https://github.com/actions/starter-workflows/tree/main/ci) repository{% else %} `actions/starter-workflows` repository on {% data variables.product.prodname_dotcom_the_website %}{% endif %}. diff --git a/content/actions/about-github-actions/understanding-github-actions.md b/content/actions/about-github-actions/understanding-github-actions.md index ab293815051d..b3ae4b838921 100644 --- a/content/actions/about-github-actions/understanding-github-actions.md +++ b/content/actions/about-github-actions/understanding-github-actions.md @@ -67,7 +67,7 @@ For a complete list of events that can be used to trigger workflows, see [Events A **job** is a set of **steps** in a workflow that is executed on the same **runner**. Each step is either a shell script that will be executed, or an **action** that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built. -You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel. When a job takes a dependency on another job, it waits for the dependent job to complete before running. +You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel. When a job takes a dependency on another job, it waits for the dependent job to complete before running. For example, you might configure multiple build jobs for different architectures without any job dependencies and a packaging job that depends on those builds. The build jobs run in parallel, and once they complete successfully, the packaging job runs. @@ -86,7 +86,7 @@ For more information on actions, see [AUTOTITLE](/actions/creating-actions). ### Runners A **runner** is a server that runs your workflows when they're triggered. Each runner can run a single **job** at a time. -{% ifversion ghes %} You must host your own runners for {% data variables.product.product_name %}. +{% ifversion ghes %} You must host your own runners for {% data variables.product.prodname_ghe_server %}. {% elsif fpt or ghec %}{% data variables.product.company_short %} provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your **workflows**. Each workflow run executes in a fresh, newly-provisioned virtual machine. {% ifversion actions-hosted-runners %} {% data variables.product.prodname_dotcom %} also offers {% data variables.actions.hosted_runner %}s, which are available in larger configurations. For more information, see [AUTOTITLE](/actions/using-github-hosted-runners/using-larger-runners). diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md index e25539a24b0d..04461ff15f93 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners.md @@ -16,7 +16,7 @@ type: overview ## About self-hosted runners -A self-hosted runner is a system that you deploy and manage to execute jobs from {% data variables.product.prodname_actions %} on {% data variables.product.product_name %}. For more information about {% data variables.product.prodname_actions %}, see [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions){% ifversion fpt %}."{% elsif ghec or ghes %} and [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises).{% endif %} +A self-hosted runner is a system that you deploy and manage to execute jobs from {% data variables.product.prodname_actions %} on {% data variables.product.github %}. For more information about {% data variables.product.prodname_actions %}, see [AUTOTITLE](/actions/learn-github-actions/understanding-github-actions){% ifversion fpt %}."{% elsif ghec or ghes %} and [AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises).{% endif %} {% data reusables.actions.self-hosted-runner-description %} {% data reusables.actions.self-hosted-runner-locations %} @@ -60,7 +60,7 @@ For more information about installing and using self-hosted runners, see [AUTOTI You can use any machine as a self-hosted runner as long at it meets these requirements: * You can install and run the self-hosted runner application on the machine. For more information, see [Supported architectures and operating systems for self-hosted runners](#supported-architectures-and-operating-systems-for-self-hosted-runners). -* The machine can communicate with {% data variables.product.prodname_actions %}. For more information, see [Communication between self-hosted runners and {% data variables.product.product_name %}](#communication-requirements). +* The machine can communicate with {% data variables.product.prodname_actions %}. For more information, see [Communication between self-hosted runners and {% data variables.product.github %}](#communication-between-self-hosted-runners-and-github). * The machine has enough hardware resources for the type of workflows you plan to run. The self-hosted runner application itself only requires minimal resources. * If you want to run workflows that use Docker container actions or service containers, you must use a Linux machine and Docker must be installed. @@ -131,9 +131,9 @@ Some extra configuration might be required to use actions from {% data variables -## Communication between self-hosted runners and {% data variables.product.product_name %} +## Communication between self-hosted runners and {% data variables.product.github %} -The self-hosted runner connects to {% data variables.product.product_name %} to receive job assignments and to download new versions of the runner application. The self-hosted runner uses an {% ifversion ghes %}HTTP(S){% else %}HTTPS{% endif %} _long poll_ that opens a connection to {% data variables.product.product_name %} for 50 seconds, and if no response is received, it then times out and creates a new long poll. The application must be running on the machine to accept and run {% data variables.product.prodname_actions %} jobs. +The self-hosted runner connects to {% ifversion fpt or ghec %}{% data variables.product.github %}{% else %}{% data variables.location.product_location_enterprise %}{% endif %} to receive job assignments and to download new versions of the runner application. The self-hosted runner uses an {% ifversion ghes %}HTTP(S){% else %}HTTPS{% endif %} _long poll_ that opens a connection to {% data variables.product.github %} for 50 seconds, and if no response is received, it then times out and creates a new long poll. The application must be running on the machine to accept and run {% data variables.product.prodname_actions %} jobs. {% data reusables.actions.self-hosted-runner-ports-protocols %} diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/configuring-the-self-hosted-runner-application-as-a-service.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/configuring-the-self-hosted-runner-application-as-a-service.md index 8df55422b8e1..dba917f89376 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/configuring-the-self-hosted-runner-application-as-a-service.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/configuring-the-self-hosted-runner-application-as-a-service.md @@ -12,7 +12,7 @@ versions: type: tutorial defaultPlatform: linux --- - + {% data reusables.actions.enterprise-github-hosted-runners %} {% capture service_first_step %}1. Stop the self-hosted runner application if it is currently running.{% endcapture %} @@ -21,7 +21,7 @@ defaultPlatform: linux {% capture service_nonwindows_intro %} > [!NOTE] -> You must add a runner to {% data variables.product.product_name %} before you can configure the self-hosted runner application as a service. +> You must add a runner to {% data variables.product.github %} before you can configure the self-hosted runner application as a service. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners). {% endcapture %} diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md index 931d8f3c612d..134d372342fc 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners.md @@ -34,9 +34,9 @@ You may not be able to create a self-hosted runner for an organization-owned rep The status can be one of the following: - * **Idle:** The runner is connected to {% data variables.product.product_name %} and is ready to execute jobs. + * **Idle:** The runner is connected to {% data variables.product.github %} and is ready to execute jobs. * **Active:** The runner is currently executing a job. - * **Offline:** The runner is not connected to {% data variables.product.product_name %}. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with {% data variables.product.product_name %}. + * **Offline:** The runner is not connected to {% data variables.product.github %}. This could be because the machine is offline, the self-hosted runner application is not running on the machine, or the self-hosted runner application cannot communicate with {% data variables.product.github %}. ## Troubleshooting network connectivity @@ -76,9 +76,9 @@ If you have any failing checks, you should also verify that your self-hosted run ### Disabling TLS certificate verification {% ifversion ghes %} -By default, the self-hosted runner application verifies the TLS certificate for {% data variables.product.product_name %}. If your {% data variables.product.product_name %} has a self-signed or internally-issued certificate, you may wish to disable TLS certificate verification for testing purposes. +By default, the self-hosted runner application verifies the TLS certificate for {% data variables.product.github %}. If {% data variables.location.product_location_enterprise %} has a self-signed or internally-issued certificate, you may wish to disable TLS certificate verification for testing purposes. {% else %} -By default, the self-hosted runner application verifies the TLS certificate for {% data variables.product.product_name %}. If you encounter network problems, you may wish to disable TLS certificate verification for testing purposes. +By default, the self-hosted runner application verifies the TLS certificate for {% data variables.product.github %}. If you encounter network problems, you may wish to disable TLS certificate verification for testing purposes. {% endif %} To disable TLS certification verification in the self-hosted runner application, set the `GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY` environment variable to `1` before configuring and running the self-hosted runner application. diff --git a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners.md b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners.md index 750c1cf3b42a..0293bc05fb15 100644 --- a/content/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners.md +++ b/content/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners.md @@ -1,6 +1,6 @@ --- title: Using a proxy server with self-hosted runners -intro: 'You can configure self-hosted runners to use a proxy server to communicate with {% data variables.product.product_name %}.' +intro: 'You can configure self-hosted runners to use a proxy server to communicate with {% data variables.product.github %}.' redirect_from: - /actions/automating-your-workflow-with-github-actions/using-a-proxy-server-with-self-hosted-runners - /actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners @@ -11,7 +11,7 @@ versions: type: tutorial shortTitle: Proxy servers --- - + {% data reusables.actions.enterprise-github-hosted-runners %} ## Configuring a proxy server using environment variables diff --git a/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/downloading-workflow-artifacts.md b/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/downloading-workflow-artifacts.md index 4646139e8a07..f85df5110520 100644 --- a/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/downloading-workflow-artifacts.md +++ b/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/downloading-workflow-artifacts.md @@ -1,7 +1,7 @@ --- title: Downloading workflow artifacts intro: You can download archived artifacts before they automatically expire. -permissions: 'People who are signed into {% data variables.product.product_name %} and have read access to a repository can download workflow artifacts.' +permissions: 'People who are signed into {% data variables.product.github %} and have read access to a repository can download workflow artifacts.' versions: fpt: '*' ghes: '*' @@ -13,7 +13,7 @@ redirect_from: {% data reusables.actions.enterprise-github-hosted-runners %} -By default, {% data variables.product.product_name %} stores build logs and artifacts for 90 days, and you can customize this retention period, depending on the type of repository. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository). +By default, {% data variables.product.github %} stores build logs and artifacts for 90 days, and you can customize this retention period, depending on the type of repository. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-retention-period-for-github-actions-artifacts-and-logs-in-your-repository). {% data reusables.repositories.permissions-statement-read %} diff --git a/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/removing-workflow-artifacts.md b/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/removing-workflow-artifacts.md index 9d5c9f2bb21d..8e9ad2f097ea 100644 --- a/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/removing-workflow-artifacts.md +++ b/content/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/removing-workflow-artifacts.md @@ -1,6 +1,6 @@ --- title: Removing workflow artifacts -intro: 'You can reclaim used {% data variables.product.prodname_actions %} storage by deleting artifacts before they expire on {% data variables.product.product_name %}.' +intro: 'You can reclaim used {% data variables.product.prodname_actions %} storage by deleting artifacts before they expire on {% data variables.product.github %}.' versions: fpt: '*' ghes: '*' diff --git a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md index 51adef23f714..66c5c8f7b115 100644 --- a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md +++ b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-circleci-to-github-actions.md @@ -36,17 +36,17 @@ For more information, see [AUTOTITLE](/actions/learn-github-actions/understandin When migrating from CircleCI, consider the following differences: * CircleCI’s automatic test parallelism automatically groups tests according to user-specified rules or historical timing information. This functionality is not built into {% data variables.product.prodname_actions %}. -* Actions that execute in Docker containers are sensitive to permissions problems since containers have a different mapping of users. You can avoid many of these problems by not using the `USER` instruction in your _Dockerfile_. For more information about the Docker filesystem on {% data variables.product.product_name %}-hosted runners, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem). +* Actions that execute in Docker containers are sensitive to permissions problems since containers have a different mapping of users. You can avoid many of these problems by not using the `USER` instruction in your _Dockerfile_. For more information about the Docker filesystem on {% data variables.product.github %}-hosted runners, see [AUTOTITLE](/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem). ## Migrating workflows and jobs -CircleCI defines `workflows` in the _config.yml_ file, which allows you to configure more than one workflow. {% data variables.product.product_name %} requires one workflow file per workflow, and as a consequence, does not require you to declare `workflows`. You'll need to create a new workflow file for each workflow configured in _config.yml_. +CircleCI defines `workflows` in the _config.yml_ file, which allows you to configure more than one workflow. {% data variables.product.github %} requires one workflow file per workflow, and as a consequence, does not require you to declare `workflows`. You'll need to create a new workflow file for each workflow configured in _config.yml_. Both CircleCI and {% data variables.product.prodname_actions %} configure `jobs` in the configuration file using similar syntax. If you configure any dependencies between jobs using `requires` in your CircleCI workflow, you can use the equivalent {% data variables.product.prodname_actions %} `needs` syntax. For more information, see [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds). ## Migrating orbs to actions -Both CircleCI and {% data variables.product.prodname_actions %} provide a mechanism to reuse and share tasks in a workflow. CircleCI uses a concept called orbs, written in YAML, to provide tasks that people can reuse in a workflow. {% data variables.product.prodname_actions %} has powerful and flexible reusable components called actions, which you build with either JavaScript files or Docker images. You can create actions by writing custom code that interacts with your repository in any way you'd like, including integrating with {% data variables.product.product_name %}'s APIs and any publicly available third-party API. For example, an action can publish npm modules, send SMS alerts when urgent issues are created, or deploy production-ready code. For more information, see [AUTOTITLE](/actions/creating-actions). +Both CircleCI and {% data variables.product.prodname_actions %} provide a mechanism to reuse and share tasks in a workflow. CircleCI uses a concept called orbs, written in YAML, to provide tasks that people can reuse in a workflow. {% data variables.product.prodname_actions %} has powerful and flexible reusable components called actions, which you build with either JavaScript files or Docker images. You can create actions by writing custom code that interacts with your repository in any way you'd like, including integrating with {% data variables.product.github %}'s APIs and any publicly available third-party API. For example, an action can publish npm modules, send SMS alerts when urgent issues are created, or deploy production-ready code. For more information, see [AUTOTITLE](/actions/creating-actions). CircleCI can reuse pieces of workflows with YAML anchors and aliases. {% data variables.product.prodname_actions %} supports the most common need for reusability using matrices. For more information about matrices, see [AUTOTITLE](/actions/using-jobs/using-a-matrix-for-your-jobs). @@ -64,7 +64,7 @@ For more information about the tools and packages available on {% data variables ## Using variables and secrets -CircleCI and {% data variables.product.prodname_actions %} support setting variables in the configuration file and creating secrets using the CircleCI or {% data variables.product.product_name %} UI. +CircleCI and {% data variables.product.prodname_actions %} support setting variables in the configuration file and creating secrets using the CircleCI or {% data variables.product.github %} UI. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables) and [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions). diff --git a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md index 54ddfa118270..20a7235cc86a 100644 --- a/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md +++ b/content/actions/migrating-to-github-actions/manually-migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions.md @@ -262,7 +262,7 @@ For more information, see [AUTOTITLE](/actions/using-workflows/events-that-trigg ## Variables and secrets -GitLab CI/CD and {% data variables.product.prodname_actions %} support setting variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.product_name %} UI. +GitLab CI/CD and {% data variables.product.prodname_actions %} support setting variables in the pipeline or workflow configuration file, and creating secrets using the GitLab or {% data variables.product.github %} UI. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables) and [AUTOTITLE](/actions/security-guides/using-secrets-in-github-actions). diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-azure-devops-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-azure-devops-with-github-actions-importer.md index 9440388bbca9..009bb51d3ac5 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-azure-devops-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-azure-devops-with-github-actions-importer.md @@ -89,7 +89,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `Azure DevOps`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "{% data variables.product.pat_generic_caps %} for Azure DevOps", enter the value for the Azure DevOps {% data variables.product.pat_generic %} that you created earlier, and press Enter. * For "Base url of the Azure DevOps instance", press Enter to accept the default value (`https://dev.azure.com`). * For "Azure DevOps organization name", enter the name for your Azure DevOps organization, and press Enter. diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bamboo-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bamboo-with-github-actions-importer.md index ee60e06abc0a..8fcfd87957f8 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bamboo-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bamboo-with-github-actions-importer.md @@ -86,7 +86,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `Bamboo`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "{% data variables.product.pat_generic_caps %} for Bamboo", enter the value for the Bamboo {% data variables.product.pat_generic %} that you created earlier, and press Enter. * For "Base url of the Bamboo instance", enter the URL for your Bamboo Server or Bamboo Data Center instance, and press Enter. diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bitbucket-pipelines-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bitbucket-pipelines-with-github-actions-importer.md index e9ba6869fe55..e7e97ea16d52 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bitbucket-pipelines-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-bitbucket-pipelines-with-github-actions-importer.md @@ -83,7 +83,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `Bitbucket`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "{% data variables.product.pat_generic_caps %} for Bitbucket", enter the Workspace Access Token that you created earlier, and press Enter. * For "Base url of the Bitbucket instance", enter the URL for your Bitbucket instance, and press Enter. diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-circleci-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-circleci-with-github-actions-importer.md index db2e0ae63b55..bc372b41f340 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-circleci-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-circleci-with-github-actions-importer.md @@ -69,7 +69,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `CircleCI`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "{% data variables.product.pat_generic_caps %} for CircleCI", enter the value for the CircleCI personal API token that you created earlier, and press Enter. * For "Base url of the CircleCI instance", press Enter to accept the default value (`https://circleci.com`). * For "CircleCI organization name", enter the name for your CircleCI organization, and press Enter. diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-gitlab-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-gitlab-with-github-actions-importer.md index 921765544b2e..2be6fefb1870 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-gitlab-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-gitlab-with-github-actions-importer.md @@ -71,7 +71,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `GitLab`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "Private token for GitLab", enter the value for the GitLab {% data variables.product.pat_generic %} that you created earlier, and press Enter. * For "Base url of the GitLab instance", enter the URL of your GitLab instance, and press Enter. @@ -192,7 +192,7 @@ You can use the `migrate` command to convert a GitLab pipeline and open a pull r To migrate a GitLab pipeline to {% data variables.product.prodname_actions %}, run the following command in your terminal, replacing the following values: -* `target-url` value with the URL for your {% data variables.product.product_name %} repository +* `target-url` value with the URL for your {% data variables.product.github %} repository * `my-gitlab-project` with your GitLab project slug * `my-gitlab-namespace` with the namespace or group you are migrating (full path for subgroups, e.g. `my-org/my-team`) diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-jenkins-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-jenkins-with-github-actions-importer.md index 1778452bcb65..9577404cc1f9 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-jenkins-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-jenkins-with-github-actions-importer.md @@ -65,7 +65,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `Jenkins`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "{% data variables.product.pat_generic_caps %} for Jenkins", enter the value for the Jenkins personal API token that you created earlier, and press Enter. * For "Username of Jenkins user", enter your Jenkins username and press Enter. * For "Base url of the Jenkins instance", enter the URL of your Jenkins instance, and press Enter. @@ -182,7 +182,7 @@ You can use the `migrate` command to convert a Jenkins pipeline and open a pull ### Running the migrate command -To migrate a Jenkins pipeline to {% data variables.product.prodname_actions %}, run the following command in your terminal, replacing the `target-url` value with the URL for your {% data variables.product.product_name %} repository, and `my-jenkins-project` with the URL for your Jenkins job. +To migrate a Jenkins pipeline to {% data variables.product.prodname_actions %}, run the following command in your terminal, replacing the `target-url` value with the URL for your {% data variables.product.github %} repository, and `my-jenkins-project` with the URL for your Jenkins job. ```shell gh actions-importer migrate jenkins --target-url https://github.com/:owner/:repo --output-dir tmp/migrate --source-url my-jenkins-project diff --git a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-travis-ci-with-github-actions-importer.md b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-travis-ci-with-github-actions-importer.md index decbab06db70..3dc16b64bebb 100644 --- a/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-travis-ci-with-github-actions-importer.md +++ b/content/actions/migrating-to-github-actions/using-github-actions-importer-to-automate-migrations/migrating-from-travis-ci-with-github-actions-importer.md @@ -72,7 +72,7 @@ The `configure` CLI command is used to set required credentials and options for * For "Which CI providers are you configuring?", use the arrow keys to select `Travis CI`, press Space to select it, then press Enter. * For "{% data variables.product.pat_generic_caps %} for GitHub", enter the value of the {% data variables.product.pat_v1 %} that you created earlier, and press Enter. - * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for your {% data variables.product.product_name %} instance, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} + * For "Base url of the GitHub instance", {% ifversion ghes %}enter the URL for {% data variables.location.product_location_enterprise %}, and press Enter.{% else %}press Enter to accept the default value (`https://github.com`).{% endif %} * For "{% data variables.product.pat_generic_caps %} for Travis CI", enter the value for the Travis CI API access token that you created earlier, and press Enter. * For "Base url of the Travis CI instance", enter the URL of your Travis CI instance, and press Enter. * For "Travis CI organization name", enter the name of your Travis CI organization, and press Enter. 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 7eec573d9122..1606f65fae74 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 @@ -28,7 +28,7 @@ The token is also available in the `github.token` context. For more information, ## Using the `GITHUB_TOKEN` in a workflow -You can use the `GITHUB_TOKEN` by using the standard syntax for referencing secrets: {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %}. Examples of using the `GITHUB_TOKEN` include passing the token as an input to an action, or using it to make an authenticated {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API request. +You can use the `GITHUB_TOKEN` by using the standard syntax for referencing secrets: {% raw %}`${{ secrets.GITHUB_TOKEN }}`{% endraw %}. Examples of using the `GITHUB_TOKEN` include passing the token as an input to an action, or using it to make an authenticated {% data variables.product.github %} API request. > [!IMPORTANT] > An action can access the `GITHUB_TOKEN` through the `github.token` context even if the workflow does not explicitly pass the `GITHUB_TOKEN` to the action. As a good security practice, you should always make sure that actions only have the minimum access they require by limiting the permissions granted to the `GITHUB_TOKEN`. For more information, see [Permissions for the `GITHUB_TOKEN`](#permissions-for-the-github_token). 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 75be3eb699f8..8835384f65a5 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 @@ -21,13 +21,13 @@ This guide explains how to configure security hardening for certain {% data vari ## Using secrets -Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/security-guides/using-secrets-in-github-actions) can be configured at the organization, repository, or environment level, and allow you to store sensitive information in {% data variables.product.product_name %}. +Sensitive values should never be stored as plaintext in workflow files, but rather as secrets. [Secrets](/actions/security-guides/using-secrets-in-github-actions) can be configured at the organization, repository, or environment level, and allow you to store sensitive information in {% data variables.product.github %}. {% ifversion fpt or ghec %} -Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.product_name %}. This occurs when the secret is submitted [using the UI](/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) or through the [REST API](/rest/actions/secrets). This client-side encryption helps minimize the risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.product_name %}'s infrastructure. Once the secret is uploaded, {% data variables.product.product_name %} is then able to decrypt it so that it can be injected into the workflow runtime. +Secrets use [Libsodium sealed boxes](https://libsodium.gitbook.io/doc/public-key_cryptography/sealed_boxes), so that they are encrypted before reaching {% data variables.product.github %}. This occurs when the secret is submitted [using the UI](/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository) or through the [REST API](/rest/actions/secrets). This client-side encryption helps minimize the risks related to accidental logging (for example, exception logs and request logs, among others) within {% data variables.product.github %}'s infrastructure. Once the secret is uploaded, {% data variables.product.github %} is then able to decrypt it so that it can be injected into the workflow runtime. {% endif %} -To help prevent accidental disclosure, {% data variables.product.product_name %} uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets used within the job, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed. Additionally, the runner can only redact secrets used within the current job. As a result, there are certain proactive steps and good practices you should follow to help ensure secrets are redacted, and to limit other risks associated with secrets: +To help prevent accidental disclosure, {% data variables.product.github %} uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets used within the job, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed. Additionally, the runner can only redact secrets used within the current job. As a result, there are certain proactive steps and good practices you should follow to help ensure secrets are redacted, and to limit other risks associated with secrets: * **Never use structured data as a secret** * Structured data can cause secret redaction within logs to fail, because redaction largely relies on finding an exact match for the specific secret value. For example, do not use a blob of JSON, XML, or YAML (or similar) to encapsulate a secret value, as this significantly reduces the probability the secrets will be properly redacted. Instead, create individual secrets for each sensitive value. @@ -152,7 +152,7 @@ With this approach, the value of the {% raw %}`${{ github.event.issue.title }}`{ ### Using workflow templates for {% data variables.product.prodname_code_scanning %} {% data reusables.advanced-security.starter-workflows-beta %} -{% data variables.product.prodname_code_scanning_caps %} allows you to find security vulnerabilities before they reach production. {% data variables.product.product_name %} provides workflow templates for {% data variables.product.prodname_code_scanning %}. You can use these suggested workflows to construct your {% data variables.product.prodname_code_scanning %} workflows, instead of starting from scratch. {% data variables.product.company_short %}'s workflow, the {% data variables.code-scanning.codeql_workflow %}, is powered by {% data variables.product.prodname_codeql %}. There are also third-party workflow templates available. +{% data variables.product.prodname_code_scanning_caps %} allows you to find security vulnerabilities before they reach production. {% data variables.product.github %} provides workflow templates for {% data variables.product.prodname_code_scanning %}. You can use these suggested workflows to construct your {% data variables.product.prodname_code_scanning %} workflows, instead of starting from scratch. {% data variables.product.company_short %}'s workflow, the {% data variables.code-scanning.codeql_workflow %}, is powered by {% data variables.product.prodname_codeql %}. There are also third-party workflow templates available. For more information, see [AUTOTITLE](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning) and [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning#configuring-code-scanning-using-third-party-actions). @@ -280,7 +280,7 @@ It is possible for an attacker to steal a job's `GITHUB_TOKEN`. The {% data vari ### Modifying the contents of a repository -The attacker server can use the {% ifversion fpt or ghec %}{% data variables.product.prodname_dotcom %}{% else %}{% data variables.product.product_name %}{% endif %} API to [modify repository content](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token), including releases, if the assigned permissions of `GITHUB_TOKEN` [are not restricted](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). +The attacker server can use the {% data variables.product.github %} API to [modify repository content](/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token), including releases, if the assigned permissions of `GITHUB_TOKEN` [are not restricted](/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token). ## Considering cross-repository access @@ -338,13 +338,13 @@ For third-party images, such as the images for ARM-powered runners, you can find **{% data variables.product.prodname_dotcom %}-hosted** runners execute code within ephemeral and clean isolated virtual machines, meaning there is no way to persistently compromise this environment, or otherwise gain access to more information than was placed in this environment during the bootstrap process. {% endif %} -{% ifversion fpt or ghec %}**Self-hosted**{% elsif ghes %}Self-hosted{% endif %} runners for {% data variables.product.product_name %} do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. +{% ifversion fpt or ghec %}**Self-hosted**{% elsif ghes %}Self-hosted{% endif %} runners for {% data variables.product.github %} do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. -{% ifversion fpt or ghec %}As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be{% elsif ghes %}Be{% endif %} cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which, depending on its settings, can grant write access to the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner. +{% ifversion fpt or ghec %}As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security) on {% data variables.product.github %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be{% elsif ghes %}Be{% endif %} cautious when using self-hosted runners on private or internal repositories, as anyone who can fork the repository and open a pull request (generally those with read access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which, depending on its settings, can grant write access to the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner. {% data reusables.actions.disable-selfhosted-runners-crossrefs %} -When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.product_name %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. You can restrict what {% ifversion restrict-groups-to-workflows %}workflows, {% endif %}organizations and repositories can access runner groups. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups). +When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.github %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. You can restrict what {% ifversion restrict-groups-to-workflows %}workflows, {% endif %}organizations and repositories can access runner groups. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups). You should also consider the environment of the self-hosted runner machines: * What sensitive information resides on the machine configured as a self-hosted runner? For example, private SSH keys, API access tokens, among others. diff --git a/content/actions/sharing-automations/creating-actions/creating-a-composite-action.md b/content/actions/sharing-automations/creating-actions/creating-a-composite-action.md index faa79ccf0324..8a0d79bde9a4 100644 --- a/content/actions/sharing-automations/creating-actions/creating-a-composite-action.md +++ b/content/actions/sharing-automations/creating-actions/creating-a-composite-action.md @@ -33,7 +33,7 @@ Composite actions allow you to collect a series of workflow job steps into a sin Before you begin, you'll create a repository on {% data variables.product.github %}. -1. Create a new public repository on {% data variables.product.github %}. You can choose any repository name, or use the following `hello-world-composite-action` example. You can add these files after your project has been pushed to {% data variables.product.product_name %}. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-new-repository). +1. Create a new public repository on {% data variables.product.github %}. You can choose any repository name, or use the following `hello-world-composite-action` example. You can add these files after your project has been pushed to {% data variables.product.github %}. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-new-repository). 1. Clone your repository to your computer. For more information, see [AUTOTITLE](/repositories/creating-and-managing-repositories/cloning-a-repository). diff --git a/content/actions/sharing-automations/creating-actions/creating-a-docker-container-action.md b/content/actions/sharing-automations/creating-actions/creating-a-docker-container-action.md index 5a18bb49ffd9..16fbe595a0c4 100644 --- a/content/actions/sharing-automations/creating-actions/creating-a-docker-container-action.md +++ b/content/actions/sharing-automations/creating-actions/creating-a-docker-container-action.md @@ -162,7 +162,7 @@ with: who-to-greet: 'Mona the Octocat' ``` -## Commit, tag, and push your action to {% data variables.product.product_name %} +## Commit, tag, and push your action From your terminal, commit your `action.yml`, `entrypoint.sh`, `Dockerfile`, and `README.md` files. diff --git a/content/actions/sharing-automations/creating-actions/creating-a-javascript-action.md b/content/actions/sharing-automations/creating-actions/creating-a-javascript-action.md index 0eaf12bd5763..b1869caa241e 100644 --- a/content/actions/sharing-automations/creating-actions/creating-a-javascript-action.md +++ b/content/actions/sharing-automations/creating-actions/creating-a-javascript-action.md @@ -167,9 +167,9 @@ with: ``` ```` -## Commit, tag, and push your action to GitHub +## Commit, tag, and push your action -{% data variables.product.product_name %} downloads each action run in a workflow during runtime and executes it as a complete package of code before you can use workflow commands like `run` to interact with the runner machine. This means you must include any package dependencies required to run the JavaScript code. You'll need to check in the toolkit `core` and `github` packages to your action's repository. +{% data variables.product.github %} downloads each action run in a workflow during runtime and executes it as a complete package of code before you can use workflow commands like `run` to interact with the runner machine. This means you must include any package dependencies required to run the JavaScript code. You'll need to check in the toolkit `core` and `github` packages to your action's repository. From your terminal, commit your `action.yml`, `index.js`, `node_modules`, `package.json`, `package-lock.json`, and `README.md` files. If you added a `.gitignore` file that lists `node_modules`, you'll need to remove that line to commit the `node_modules` directory. diff --git a/content/actions/sharing-automations/creating-actions/developing-a-third-party-cli-action.md b/content/actions/sharing-automations/creating-actions/developing-a-third-party-cli-action.md index 01ed43db4285..6647da5ee416 100644 --- a/content/actions/sharing-automations/creating-actions/developing-a-third-party-cli-action.md +++ b/content/actions/sharing-automations/creating-actions/developing-a-third-party-cli-action.md @@ -21,7 +21,7 @@ Your action should: * Make it simple for users to specify the version of the CLI to install * Support multiple operating systems * Run in an efficient fashion to minimize run-time and associated costs -* Work across {% data variables.product.product_name %}-hosted and self-hosted runners +* Work across {% data variables.product.github %}-hosted and self-hosted runners * Leverage community tooling when possible This article will demonstrate how to write an action that retrieves a specific version of your CLI, installs it, adds it to the path, and (optionally) caches it. This type of action (an action that sets up a tool) is often named `setup-$TOOL`. diff --git a/content/actions/sharing-automations/creating-actions/dockerfile-support-for-github-actions.md b/content/actions/sharing-automations/creating-actions/dockerfile-support-for-github-actions.md index c304e80b65fb..6d0a6495053c 100644 --- a/content/actions/sharing-automations/creating-actions/dockerfile-support-for-github-actions.md +++ b/content/actions/sharing-automations/creating-actions/dockerfile-support-for-github-actions.md @@ -38,7 +38,7 @@ These are some best practices when setting the `FROM` argument: ### WORKDIR -{% data variables.product.product_name %} sets the working directory path in the `GITHUB_WORKSPACE` environment variable. It's recommended to not use the `WORKDIR` instruction in your `Dockerfile`. Before the action executes, {% data variables.product.product_name %} will mount the `GITHUB_WORKSPACE` directory on top of anything that was at that location in the Docker image and set `GITHUB_WORKSPACE` as the working directory. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables) and the [WORKDIR reference](https://docs.docker.com/engine/reference/builder/#workdir) in the Docker documentation. +{% data variables.product.github %} sets the working directory path in the `GITHUB_WORKSPACE` environment variable. It's recommended to not use the `WORKDIR` instruction in your `Dockerfile`. Before the action executes, {% data variables.product.github %} will mount the `GITHUB_WORKSPACE` directory on top of anything that was at that location in the Docker image and set `GITHUB_WORKSPACE` as the working directory. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables#default-environment-variables) and the [WORKDIR reference](https://docs.docker.com/engine/reference/builder/#workdir) in the Docker documentation. ### ENTRYPOINT @@ -77,7 +77,7 @@ ENTRYPOINT ["/entrypoint.sh"] #### Example _entrypoint.sh_ file -Using the example Dockerfile above, {% data variables.product.product_name %} will send the `args` configured in the action's metadata file as arguments to `entrypoint.sh`. Add the `#!/bin/sh` [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) at the top of the `entrypoint.sh` file to explicitly use the system's [POSIX](https://en.wikipedia.org/wiki/POSIX)-compliant shell. +Using the example Dockerfile above, {% data variables.product.github %} will send the `args` configured in the action's metadata file as arguments to `entrypoint.sh`. Add the `#!/bin/sh` [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) at the top of the `entrypoint.sh` file to explicitly use the system's [POSIX](https://en.wikipedia.org/wiki/POSIX)-compliant shell. ```shell #!/bin/sh diff --git a/content/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions.md b/content/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions.md index 8e487ea6a326..58981712c9d5 100644 --- a/content/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions.md +++ b/content/actions/sharing-automations/creating-actions/releasing-and-maintaining-actions.md @@ -80,13 +80,13 @@ Using semantic releases means that the users of your actions can pin their workf ## Working with the community -{% data variables.product.product_name %} provides tools and guides to help you work with the open source community. Here are a few tools we recommend setting up for healthy bidirectional communication. By providing the following signals to the community, you encourage others to use, modify, and contribute to your action: +{% data variables.product.github %} provides tools and guides to help you work with the open source community. Here are a few tools we recommend setting up for healthy bidirectional communication. By providing the following signals to the community, you encourage others to use, modify, and contribute to your action: * Maintain a `README` with plenty of usage examples and guidance. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes). * Include a workflow status badge in your `README` file. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge). Also visit [shields.io](https://shields.io/) to learn about other badges that you can add.{% ifversion fpt or ghec %} * Add community health files like `CODE_OF_CONDUCT`, `CONTRIBUTING`, and `SECURITY`. For more information, see [AUTOTITLE](/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file#supported-file-types).{% endif %} * Keep issues current by utilizing actions like [actions/stale](https://github.com/actions/stale).{% ifversion fpt or ghec %} -* Use {% data variables.product.product_name %}'s security features to communicate about vulnerabilities and how to fix them. For more information, see [AUTOTITLE](/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions#protecting-actions-youve-created).{% endif %} +* Use {% data variables.product.github %}'s security features to communicate about vulnerabilities and how to fix them. For more information, see [AUTOTITLE](/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions#protecting-actions-youve-created).{% endif %} ## Further reading diff --git a/content/actions/use-cases-and-examples/publishing-packages/publishing-docker-images.md b/content/actions/use-cases-and-examples/publishing-packages/publishing-docker-images.md index 1987e5c61a38..381fcf910c9f 100644 --- a/content/actions/use-cases-and-examples/publishing-packages/publishing-docker-images.md +++ b/content/actions/use-cases-and-examples/publishing-packages/publishing-docker-images.md @@ -50,7 +50,7 @@ In this guide, we will use the Docker `build-push-action` action to build the Do ## Publishing images to Docker Hub -Each time you create a new release on {% data variables.product.product_name %}, you can trigger a workflow to publish your image. The workflow in the example below runs when the `release` event triggers with the `published` activity type. +Each time you create a new release on {% data variables.product.github %}, you can trigger a workflow to publish your image. The workflow in the example below runs when the `release` event triggers with the `published` activity type. In the example workflow below, we use the Docker `login-action` and `build-push-action` actions to build the Docker image and, if the build succeeds, push the built image to Docker Hub. @@ -132,7 +132,7 @@ The above workflow checks out the {% data variables.product.prodname_dotcom %} r {% data reusables.package_registry.container-registry-ghes-beta %} {% endif %} -Each time you create a new release on {% data variables.product.product_name %}, you can trigger a workflow to publish your image. The workflow in the example below runs when a change is pushed to the `release` branch. +Each time you create a new release on {% data variables.product.github %}, you can trigger a workflow to publish your image. The workflow in the example below runs when a change is pushed to the `release` branch. In the example workflow below, we use the Docker `login-action`{% ifversion fpt or ghec %}, `metadata-action`,{% endif %} and `build-push-action` actions to build the Docker image, and if the build succeeds, push the built image to {% data variables.product.prodname_registry %}. @@ -235,7 +235,7 @@ jobs: {% endif -%} ``` -The above workflow checks out the {% data variables.product.product_name %} repository, uses the `login-action` twice to log in to both registries and generates tags and labels with the `metadata-action` action. +The above workflow checks out the {% data variables.product.github %} repository, uses the `login-action` twice to log in to both registries and generates tags and labels with the `metadata-action` action. Then the `build-push-action` action builds and pushes the Docker image to Docker Hub and the {% data variables.product.prodname_container_registry %}. {% ifversion artifact-attestations %}{% data reusables.actions.artifact-attestations-step-explanation %}{% endif %} diff --git a/content/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners.md b/content/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners.md index 6e767be88068..b73efd30d02b 100644 --- a/content/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners.md +++ b/content/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners.md @@ -212,11 +212,11 @@ Since there are so many IP address ranges for {% data variables.product.prodname The list of {% data variables.product.prodname_actions %} IP addresses returned by the API is updated once a week. -## Communication requirements for {% data variables.product.prodname_dotcom %}-hosted runners and {% data variables.product.product_name %} +## Communication requirements for {% data variables.product.prodname_dotcom %}-hosted runners -A {% data variables.product.prodname_dotcom %}-hosted runner must establish connections to {% data variables.product.prodname_dotcom %}-owned endpoints to perform essential communication operations. In addition, your runner may require access to additional networks that you specify or utilize within an action. +A {% data variables.product.github %}-hosted runner must establish connections to {% data variables.product.github %}-owned endpoints to perform essential communication operations. In addition, your runner may require access to additional networks that you specify or utilize within an action. -To ensure proper communications for {% data variables.product.prodname_dotcom %}-hosted runners between networks within your configuration, ensure that the following communications are allowed. +To ensure proper communications for {% data variables.product.github %}-hosted runners between networks within your configuration, ensure that the following communications are allowed. {% data reusables.actions.domain-name-cname-recursive-firewall-rules %} diff --git a/content/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables.md b/content/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables.md index 2ded804dd12d..6c5ac80caf91 100644 --- a/content/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables.md +++ b/content/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables.md @@ -284,7 +284,7 @@ We strongly recommend that actions use variables to access the filesystem rather | `GITHUB_RUN_ATTEMPT` | A unique number for each attempt of a particular workflow run in a repository. This number begins at 1 for the workflow run's first attempt, and increments with each re-run. For example, `3`. | | `GITHUB_RUN_ID` | {% data reusables.actions.run_id_description %} For example, `1658821493`. | | `GITHUB_RUN_NUMBER` | {% data reusables.actions.run_number_description %} For example, `3`. | -| `GITHUB_SERVER_URL`| The URL of the {% data variables.product.product_name %} server. For example: `https://{% data variables.product.product_url %}`. | +| `GITHUB_SERVER_URL`| The URL of {% data variables.location.product_location_enterprise %}. For example: `https://{% data variables.product.product_url %}`. | | `GITHUB_SHA` | {% data reusables.actions.github_sha_description %} | | `GITHUB_STEP_SUMMARY` | The path on the runner to the file that contains job summaries from workflow commands. The path to this file is unique to the current step and changes for each step in a job. For example, `/home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c`. For more information, see [AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary). | | `GITHUB_TRIGGERING_ACTOR` | {% data reusables.actions.github-triggering-actor-description %} | diff --git a/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md b/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md index e22261b69a61..ed1803ed6b40 100644 --- a/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md +++ b/content/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow.md @@ -37,7 +37,7 @@ These are some of the common artifacts that you can upload: {% ifversion fpt or ghec %} -Storing artifacts uses storage space on {% data variables.product.product_name %}. {% data reusables.actions.actions-billing %} For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions). +Storing artifacts uses storage space on {% data variables.product.github %}. {% data reusables.actions.actions-billing %} For more information, see [AUTOTITLE](/billing/managing-billing-for-github-actions). {% else %} @@ -45,9 +45,9 @@ Artifacts consume storage space on the external blob storage that is configured {% endif %} -Artifacts are uploaded during a workflow run, and you can view an artifact's name and size in the UI. When an artifact is downloaded using the {% data variables.product.product_name %} UI, all files that were individually uploaded as part of the artifact get zipped together into a single file. This means that billing is calculated based on the size of the uploaded artifact and not the size of the zip file. +Artifacts are uploaded during a workflow run, and you can view an artifact's name and size in the UI. When an artifact is downloaded using the {% data variables.product.github %} UI, all files that were individually uploaded as part of the artifact get zipped together into a single file. This means that billing is calculated based on the size of the uploaded artifact and not the size of the zip file. -{% data variables.product.product_name %} provides two actions that you can use to upload and download build artifacts. For more information, see the {% ifversion fpt or ghec %}[upload-artifact](https://github.com/actions/upload-artifact) and [download-artifact](https://github.com/actions/download-artifact) actions{% else %} `upload-artifact` and `download-artifact` actions on {% data variables.product.prodname_ghe_server %}{% endif %}. +{% data variables.product.github %} provides two actions that you can use to upload and download build artifacts. For more information, see the {% ifversion fpt or ghec %}[upload-artifact](https://github.com/actions/upload-artifact) and [download-artifact](https://github.com/actions/download-artifact) actions{% else %} `upload-artifact` and `download-artifact` actions on {% data variables.product.prodname_ghe_server %}{% endif %}. To share data between jobs: diff --git a/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md b/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md index 23a054968148..e23804f047bc 100644 --- a/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md +++ b/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md @@ -1,6 +1,6 @@ --- title: Events that trigger workflows -intro: 'You can configure your workflows to run when specific activity on {% data variables.product.product_name %} happens, at a scheduled time, or when an event outside of {% data variables.product.product_name %} occurs.' +intro: 'You can configure your workflows to run when specific activity on {% data variables.product.github %} happens, at a scheduled time, or when an event outside of {% data variables.product.github %} occurs.' redirect_from: - /articles/events-that-trigger-workflows - /github/automating-your-workflow-with-github-actions/events-that-trigger-workflows @@ -956,7 +956,7 @@ on: > {% data reusables.developer-site.multiple_activity_types %} For information about each activity type, see [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#release). {% data reusables.developer-site.limit_workflow_to_activity_types %} > [!NOTE] -> Workflows are not triggered for the `created`, `edited`, or `deleted` activity types for draft releases. When you create your release through the {% data variables.product.product_name %} browser UI, your release may automatically be saved as a draft. +> Workflows are not triggered for the `created`, `edited`, or `deleted` activity types for draft releases. When you create your release through the {% data variables.product.github %} UI, your release may automatically be saved as a draft. > [!NOTE] > The `prereleased` type will not trigger for pre-releases published from draft releases, but the `published` type will trigger. If you want a workflow to run when stable _and_ pre-releases publish, subscribe to `published` instead of `released` and `prereleased`. @@ -979,7 +979,7 @@ on: {% data reusables.actions.branch-requirement %} -You can use the {% data variables.product.product_name %} API to trigger a webhook event called [`repository_dispatch`](/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.product_name %}. For more information, see [AUTOTITLE](/rest/repos/repos#create-a-repository-dispatch-event). +You can use the {% data variables.product.github %} API to trigger a webhook event called [`repository_dispatch`](/webhooks-and-events/webhooks/webhook-events-and-payloads#repository_dispatch) when you want to trigger a workflow for activity that happens outside of {% data variables.product.github %}. For more information, see [AUTOTITLE](/rest/repos/repos#create-a-repository-dispatch-event). When you make a request to create a `repository_dispatch` event, you must specify an `event_type` to describe the activity type. By default, all `repository_dispatch` activity types trigger a workflow to run. You can use the `types` keyword to limit your workflow to run when a specific `event_type` value is sent in the `repository_dispatch` webhook payload. @@ -1158,7 +1158,7 @@ on: workflow_call {% data reusables.actions.branch-requirement %} -To enable a workflow to be triggered manually, you need to configure the `workflow_dispatch` event. You can manually trigger a workflow run using the {% data variables.product.product_name %} API, {% data variables.product.prodname_cli %}, or {% data variables.product.product_name %} browser interface. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/manually-running-a-workflow). +To enable a workflow to be triggered manually, you need to configure the `workflow_dispatch` event. You can manually trigger a workflow run using the {% data variables.product.github %} API, {% data variables.product.prodname_cli %}, or the {% data variables.product.github %} UI. For more information, see [AUTOTITLE](/actions/managing-workflow-runs/manually-running-a-workflow). ```yaml on: workflow_dispatch @@ -1320,7 +1320,7 @@ jobs: path: pr/ ``` -When a run of the above workflow completes, it triggers a run of the following workflow. The following workflow uses the `github.event.workflow_run` context and the {% data variables.product.product_name %} REST API to download the artifact that was uploaded by the above workflow, unzips the downloaded artifact, and comments on the pull request whose number was uploaded as an artifact. +When a run of the above workflow completes, it triggers a run of the following workflow. The following workflow uses the `github.event.workflow_run` context and the {% data variables.product.github %} REST API to download the artifact that was uploaded by the above workflow, unzips the downloaded artifact, and comments on the pull request whose number was uploaded as an artifact. ```yaml name: Use the data diff --git a/content/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow.md b/content/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow.md index 123087811df9..0182b3de299f 100644 --- a/content/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow.md +++ b/content/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow.md @@ -26,10 +26,10 @@ Workflow triggers are defined with the `on` key. For more information, see [AUTO The following steps occur to trigger a workflow run: 1. An event occurs on your repository. The event has an associated commit SHA and Git ref. -1. {% data variables.product.product_name %} searches the `.github/workflows` directory in the root of your repository for workflow files that are present in the associated commit SHA or Git ref of the event. +1. {% data variables.product.github %} searches the `.github/workflows` directory in the root of your repository for workflow files that are present in the associated commit SHA or Git ref of the event. 1. A workflow run is triggered for any workflows that have `on:` values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run. - Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, {% data variables.product.product_name %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables). + Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, {% data variables.product.github %} sets the `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (Git ref) environment variables in the runner environment. For more information, see [AUTOTITLE](/actions/learn-github-actions/variables). ### Triggering a workflow from a workflow diff --git a/content/actions/writing-workflows/using-workflow-templates.md b/content/actions/writing-workflows/using-workflow-templates.md index 2c5b48610636..c3f5f8656a2f 100644 --- a/content/actions/writing-workflows/using-workflow-templates.md +++ b/content/actions/writing-workflows/using-workflow-templates.md @@ -1,7 +1,7 @@ --- title: Using workflow templates shortTitle: Use workflow templates -intro: '{% data variables.product.product_name %} provides workflow templates for a variety of languages and tooling.' +intro: '{% data variables.product.github %} provides workflow templates for a variety of languages and tooling.' redirect_from: - /articles/setting-up-continuous-integration-using-github-actions - /github/automating-your-workflow-with-github-actions/setting-up-continuous-integration-using-github-actions @@ -29,13 +29,13 @@ topics: Workflow templates are templates that help you to create your own {% data variables.product.prodname_actions %} workflows for a repository. They offer an alternative to starting from a blank workflow file and are useful because some of the work will already have been done for you. -{% data variables.product.product_name %} offers workflow templates for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.product_name %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use Node.js, {% data variables.product.product_name %} will suggest a workflow template file that installs your Node.js packages and runs your tests. You can search and filter to find relevant workflow templates. +{% data variables.product.github %} offers workflow templates for a variety of languages and tooling. When you set up workflows in your repository, {% data variables.product.github %} analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use Node.js, {% data variables.product.github %} will suggest a workflow template file that installs your Node.js packages and runs your tests. You can search and filter to find relevant workflow templates. {% data reusables.actions.workflow-templates-categories %} {% data reusables.actions.workflow-templates-repo-link %} -You can also create your own workflow template to share with your organization. These workflow templates will appear alongside the {% data variables.product.product_name %}-provided workflow templates. Anyone with write access to the organization's `.github` repository can set up a workflow template. For more information, see [AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization). +You can also create your own workflow template to share with your organization. These workflow templates will appear alongside the {% data variables.product.github %}-provided workflow templates. Anyone with write access to the organization's `.github` repository can set up a workflow template. For more information, see [AUTOTITLE](/actions/using-workflows/creating-starter-workflows-for-your-organization). ## Choosing and using a workflow template