| title | shortTitle | intro | versions | type | topics | redirect_from | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Introducing GitHub Actions to your enterprise |
Introduce Actions |
You can plan how to roll out {% data variables.product.prodname_actions %} in your enterprise. |
|
how_to |
|
|
{% data reusables.actions.about-actions %} With {% data variables.product.prodname_actions %}, your enterprise can automate, customize, and execute your software development workflows like testing and deployments. For more information, see AUTOTITLE.
Before you introduce {% data variables.product.prodname_actions %} to a large enterprise, you first need to plan your adoption and make decisions about how your enterprise will use {% data variables.product.prodname_actions %} to best support your unique needs.
You should create a plan to govern your enterprise's use of {% data variables.product.prodname_actions %} and meet your compliance obligations.
Determine which actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %} your developers will be allowed to use. {% ifversion ghes %}First, decide whether you'll enable access to actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %} from outside your instance. {% data reusables.actions.access-actions-on-dotcom %} For more information, see AUTOTITLE.
Then,{% else %}First,{% endif %} decide whether you'll allow third-party actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %} that were not created by {% data variables.product.company_short %}. You can configure the actions {% ifversion actions-workflow-policy %}and reusable workflows{% endif %} that are allowed to run at the repository, organization, and enterprise levels and can choose to only allow actions that are created by {% data variables.product.company_short %}. If you do allow third-party actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}, you can limit allowed actions to those created by verified creators or a list of specific actions{% ifversion actions-workflow-policy %} and reusable workflows{% endif %}.
For more information, see AUTOTITLE, AUTOTITLE, and AUTOTITLE.
Consider combining OpenID Connect (OIDC) with reusable workflows to enforce consistent deployments across your repository, organization, or enterprise. You can do this by defining trust conditions on cloud roles based on reusable workflows. For more information, see AUTOTITLE.
You can access information about activity related to {% data variables.product.prodname_actions %} in the audit logs for your enterprise. If your business needs require retaining this information longer than audit log data is retained, plan how you'll export and store this data outside of {% data variables.product.prodname_dotcom %}. For more information, see {% ifversion ghec %}AUTOTITLE and AUTOTITLE.{% else %}AUTOTITLE and AUTOTITLE.{% endif %}
{% ifversion custom-org-roles %}You can practice the principle of least privilege by administering custom organization roles for access to settings in your {% data variables.product.prodname_actions %} CI/CD pipeline. For more information about custom organization roles, see AUTOTITLE.{% endif %}
You should plan your approach to security hardening for {% data variables.product.prodname_actions %}.
Make a plan to enforce good security practices for people using {% data variables.product.prodname_actions %} features within your enterprise. For more information about these practices, see AUTOTITLE.
You can also encourage reuse of workflows that have already been evaluated for security. For more information, see Innersourcing.
You should plan where you'll store your secrets. We recommend storing secrets in {% data variables.product.prodname_dotcom %}, but you might choose to store secrets in a cloud provider.
In {% data variables.product.prodname_dotcom %}, you can store secrets at the repository or organization level. Secrets at the repository level can be limited to workflows in certain environments, such as production or testing. For more information, see AUTOTITLE.
You should consider adding manual approval protection for sensitive environments, so that workflows must be approved before getting access to the environments' secrets. For more information, see AUTOTITLE.
There is significant risk in sourcing actions from third-party repositories on {% data variables.product.prodname_dotcom %}. If you do allow any third-party actions, you should create internal guidelines that encourage your team to follow best practices, such as pinning actions to the full commit SHA. For more information, see AUTOTITLE.
{% ifversion ghec %}
{% data reusables.actions.azure-vnet-network-configuration-intro %} For more information, see AUTOTITLE.
{% endif %}
Think about how your enterprise can use features of {% data variables.product.prodname_actions %} to innersource automation. Innersourcing is a way to incorporate the benefits of open source methodologies into your internal software development cycle. For more information, see An introduction to innersource in {% data variables.product.company_short %} Resources.
{% data reusables.actions.internal-actions-summary %}
With reusable workflows, your team can call one workflow from another workflow, avoiding exact duplication. Reusable workflows promote best practice by helping your team use workflows that are well designed and have already been tested. For more information, see AUTOTITLE.
To provide a starting place for developers building new workflows, you can use workflow templates. This not only saves time for your developers, but promotes consistency and best practice across your enterprise. For more information, see AUTOTITLE.
You should plan for how you'll manage the resources required to use {% data variables.product.prodname_actions %}.
{% ifversion ghes %}
You may need to upgrade the CPU and memory resources for {% data variables.location.product_location %} to handle the load from {% data variables.product.prodname_actions %} without causing performance loss. For more information, see AUTOTITLE. {% endif %}
{% data variables.product.prodname_actions %} workflows require runners.{% ifversion ghec %} You can choose to use {% data variables.product.prodname_dotcom %}-hosted runners or self-hosted runners. {% data variables.product.company_short %} manages maintenance and upgrades for {% data variables.product.prodname_dotcom %}-hosted runners. For more information, see AUTOTITLE.
To manage your own resources, configuration, or geographic location of your runner machines, use self-hosted runners. For more information, see AUTOTITLE.
If you want more control over the networking policies for your runners, use self-hosted runners or private networking options for {% data variables.product.prodname_dotcom %}-hosted runners. For more information about private networking options, see AUTOTITLE.{% else %} You will need to host your own runners by installing the {% data variables.product.prodname_actions %} self-hosted runner application on your own machines. For more information, see AUTOTITLE.{% endif %}
{% ifversion ghec %}If you are using self-hosted runners, you have to decide whether you want to use physical machines, virtual machines, or containers.{% else %}Decide whether you want to use physical machines, virtual machines, or containers for your self-hosted runners.{% endif %} Physical machines will retain remnants of previous jobs, and so will virtual machines unless you use a fresh image for each job or clean up the machines after each job run. If you choose containers, you should be aware that the runner auto-updating will shut down the container, which can cause workflows to fail. You should come up with a solution for this by preventing auto-updates or skipping the command to kill the container.
You also have to decide where to add each runner. You can add a self-hosted runner to an individual repository, or you can make the runner available to an entire organization or your entire enterprise. Adding runners at the organization or enterprise levels allows sharing of runners, which might reduce the size of your runner infrastructure. You can use policies to limit access to self-hosted runners at the organization and enterprise levels by assigning groups of runners to specific repositories or organizations. For more information, see AUTOTITLE and AUTOTITLE. You can also use policies to prevent people using repository-level self-hosted runners. For more information, see AUTOTITLE.
You should consider using autoscaling to automatically increase or decrease the number of available self-hosted runners. For more information, see AUTOTITLE.
Finally, you should consider security hardening for self-hosted runners. For more information, see AUTOTITLE.
{% data reusables.actions.about-artifacts %} For more information, see AUTOTITLE.
{% data variables.product.prodname_actions %} also has a caching system that you can use to cache dependencies to speed up workflow runs. For more information, see AUTOTITLE. {% ifversion ghes %} You must configure external blob storage for workflow artifacts, caches, and other workflow logs. Decide which supported storage provider your enterprise will use. For more information, see AUTOTITLE. {% endif %}
You can use policy settings for {% data variables.product.prodname_actions %} to customize the storage of workflow artifacts, caches, and log retention. For more information, see AUTOTITLE.
{% ifversion ghec %} Some storage is included in your subscription, but additional storage will affect your bill. You should plan for this cost. For more information, see AUTOTITLE. {% endif %}
You should consider making a plan to track your enterprise's usage of {% data variables.product.prodname_actions %}, such as how often workflows are running, how many of those runs are passing and failing, and which repositories are using which workflows.
{% ifversion ghec %} You can see basic details of storage and data transfer usage of {% data variables.product.prodname_actions %} for each organization in your enterprise via your billing settings. For more information, see AUTOTITLE.
[!NOTE] Enterprise-level metrics for {% data variables.product.prodname_actions %} is in {% data variables.release-phases.public_preview %} and subject to change.
You can view both usage and performance data for your enterprise under the "Insights" tab. These metrics provide the same {% data variables.product.prodname_actions %} data available at the repository and organization levels but aggregated for your entire enterprise. If you need more detailed insights, see Viewing {% data variables.product.prodname_actions %} metrics for your organization or Viewing {% data variables.product.prodname_actions %} metrics for your repository.
For more detailed usage data at a per job or per workflow level, you{% else %}You{% endif %} can use webhooks to subscribe to information about workflow jobs and workflow runs. For more information, see AUTOTITLE.
Make a plan for how your enterprise can pass the information from these webhooks into a data archiving system. You can consider using "CEDAR.GitHub.Collector", an open source tool that collects and processes webhook data from {% data variables.product.prodname_dotcom %}. For more information, see the Microsoft/CEDAR.GitHub.Collector repository.
You should also plan how you'll enable your teams to get the data they need from your archiving system.