About GitHub Actions permissions for your repository
By default, GitHub Actions is enabled on all repositories and organizations. You can choose to disable GitHub Actions or limit it to actions and reusable workflows in your organization. For more information about GitHub Actions, see "Writing workflows."
You can enable GitHub Actions for your repository. When you enable GitHub Actions, workflows are able to run actions and reusable workflows located within your repository and any other public repository. You can disable GitHub Actions for your repository altogether. When you disable GitHub Actions, no workflows run in your repository.
Alternatively, you can enable GitHub Actions in your repository but limit the actions and reusable workflows a workflow can run.
Managing GitHub Actions permissions for your repository
You can disable GitHub Actions for a repository, or set a policy that configures which actions and reusable workflows can be used in the repository.
Note: You might not be able to manage these settings if your organization has an overriding policy or is managed by an enterprise that has overriding policy. For more information, see "Disabling or limiting GitHub Actions for your organization" or "Enforcing policies for GitHub Actions in your enterprise."
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under "Actions permissions", select an option.
If you choose Allow OWNER, and select non-OWNER, actions and reusable workflows, actions and reusable workflows within your organization are allowed, and there are additional options for allowing other specific actions and reusable workflows. For more information, see "Allowing select actions and reusable workflows to run."
When you allow actions and reusable workflows from only in your organization, the policy blocks all access to actions authored by GitHub. For example, the
actions/checkout
action would not be accessible. -
Click Save.
Allowing select actions and reusable workflows to run
When you choose Allow OWNER, and select non-OWNER, actions and reusable workflows, local actions and reusable workflows are allowed, and there are additional options for allowing other specific actions and reusable workflows:
Note: You might not be able to manage these settings if your organization has an overriding policy or is managed by an enterprise that has overriding policy. For more information, see "Disabling or limiting GitHub Actions for your organization" or "Enforcing policies for GitHub Actions in your enterprise."
-
Allow actions created by GitHub: You can allow all actions created by GitHub to be used by workflows. Actions created by GitHub are located in the
actions
andgithub
organizations. For more information, see theactions
andgithub
organizations. -
Allow Marketplace actions by verified creators: You can allow all GitHub Marketplace actions created by verified creators to be used by workflows. When GitHub has verified the creator of the action as a partner organization, the badge is displayed next to the action in GitHub Marketplace.
-
Allow specified actions and reusable workflows: You can restrict workflows to use actions and reusable workflows in specific organizations and repositories. Specified actions cannot be set to more than 1000.
To restrict access to specific tags or commit SHAs of an action or reusable workflow, use the same syntax used in the workflow to select the action or reusable workflow.
- For an action, the syntax is
OWNER/REPOSITORY@TAG-OR-SHA
. For example, useactions/javascript-action@v1.0.1
to select a tag oractions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f
to select a SHA. For more information, see "Using pre-written building blocks in your workflow." - For a reusable workflow, the syntax is
OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA
. For example,octo-org/another-repo/.github/workflows/workflow.yml@v1
. For more information, see "Reusing workflows."
You can use the
*
wildcard character to match patterns. For example, to allow all actions and reusable workflows in organizations that start withspace-org
, you can specifyspace-org*/*
. To allow all actions and reusable workflows in repositories that start with octocat, you can use*/octocat**@*
. For more information about using the*
wildcard, see "Workflow syntax for GitHub Actions."Note: For GitHub Free, GitHub Pro, GitHub Free for organizations, or GitHub Team plans, the Allow specified actions and reusable workflows option is only available in public repositories.
- For an action, the syntax is
This procedure demonstrates how to add specific actions and reusable workflows to the allow list.
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under "Actions permissions", select Allow OWNER, and select non-OWNER, actions and reusable workflows and add your required actions to the list.
-
Click Save.
Controlling changes from forks to workflows in public repositories
Anyone can fork a public repository, and then submit a pull request that proposes changes to the repository's GitHub Actions workflows. Although workflows from forks do not have access to sensitive data such as secrets, they can be an annoyance for maintainers if they are modified for abusive purposes.
To help prevent this, workflows on pull requests to public repositories from some outside contributors will not run automatically, and might need to be approved first. By default, all first-time contributors require approval to run workflows.
Note: Workflows triggered by pull_request_target
events are run in the context of the base branch. Since the base branch is considered trusted, workflows triggered by these events will always run, regardless of approval settings. For more information about the pull_request_target
event, see "Events that trigger workflows."
You can configure this behavior for a repository using the procedure below. Modifying this setting overrides the configuration set at the organization or enterprise level.
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under Fork pull request workflows from outside collaborators, choose one of the options.
- Require approval for first-time contributors who are new to GitHub. This option requires approval to run workflows for users who have never committed to the repository and have new GitHub accounts.
- Require approval for first-time contributors. This option requires approval to run workflows for users who have never committed to the repository.
- Require approval for all outside collaborators. This option requires approval to run workflows for all users who are not repository collaborators. If the repository is owned by an organization, this option requires approval to run workflows for all repository collaborators who are not organization members.
-
Click Save to apply the settings.
For more information about approving workflow runs that this policy applies to, see "Approving workflow runs from public forks."
Enabling workflows for forks of private repositories
If you rely on using forks of your private repositories, you can configure policies that control how users can run workflows on pull_request
events. Available to private repositories only, you can configure these policy settings for organizations or repositories.
If a policy is disabled for an organization, it cannot be enabled for a repository.
- Run workflows from fork pull requests - Allows users to run workflows from fork pull requests, using a
GITHUB_TOKEN
with read-only permission, and with no access to secrets. - Send write tokens to workflows from pull requests - Allows pull requests from forks to use a
GITHUB_TOKEN
with write permission. - Send secrets to workflows from pull requests - Makes all secrets available to the pull request.
- Require approval for fork pull request workflows - Workflow runs on pull requests from collaborators without write permission will require approval from someone with write permission before they will run.
Configuring the fork policy for a private repository
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under Fork pull request workflows, select your options.
-
Click Save to apply the settings.
Setting the permissions of the GITHUB_TOKEN
for your repository
You can set the default permissions granted to the GITHUB_TOKEN
. For more information about the GITHUB_TOKEN
, see "Automatic token authentication." You can choose a restricted set of permissions as the default, or apply permissive settings.
The default permissions can also be configured in the organization settings. If your repository belongs to an organization and a more restrictive default has been selected in the organization settings, the same option is selected in your repository settings and the permissive option is disabled.
Anyone with write access to a repository can modify the permissions granted to the GITHUB_TOKEN
, adding or removing access as required, by editing the permissions
key in the workflow file. For more information, see permissions
.
Configuring the default GITHUB_TOKEN
permissions
By default, when you create a new repository in your personal account, GITHUB_TOKEN
only has read access for the contents
and packages
scopes. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings.
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under "Workflow permissions", choose whether you want the
GITHUB_TOKEN
to have read and write access for all permissions (the permissive setting), or just read access for thecontents
andpackages
permissions (the restricted setting). -
Click Save to apply the settings.
Preventing GitHub Actions from creating or approving pull requests
You can choose to allow or prevent GitHub Actions workflows from creating or approving pull requests.
By default, when you create a new repository in your personal account, workflows are not allowed to create or approve pull requests. If you create a new repository in an organization, the setting is inherited from what is configured in the organization settings.
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under "Workflow permissions", use the Allow GitHub Actions to create and approve pull requests setting to configure whether
GITHUB_TOKEN
can create and approve pull requests. -
Click Save to apply the settings.
Allowing access to components in a private repository
Actions and reusable workflows in your private repositories can be shared with other private repositories owned by the same user or organization. For information about private repositories, see "About repositories."
You can use the steps below to configure whether actions and reusable workflows in a private repository can be accessed from outside the repository. For more information, see "Sharing actions and workflows from your private repository" and "Sharing actions and workflows with your organization." Alternatively, you can use the REST API to set, or get details of the level of access. For more information, see "REST API endpoints for GitHub Actions permissions" and "REST API endpoints for GitHub Actions permissions."
Managing access for a private repository
-
On GitHub, navigate to the main page of the private repository.
-
Under your repository name, click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under Access, choose one of the access settings:
- Not accessible - Workflows in other repositories cannot access this repository.
- Accessible from repositories owned by 'USER NAME' user - Workflows in other repositories that are owned by the same user can access the actions and reusable workflows in this repository. Access is allowed only from private repositories.
-
Click Save to apply the settings.
Managing access for a private repository in an organization
-
On GitHub, navigate to the main page of the private repository.
-
Under your repository name, click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under Access, choose one of the access settings:
- Not accessible - Workflows in other repositories cannot access this repository.
- Accessible from repositories in the 'ORGANIZATION NAME' organization - Workflows in other repositories that are part of the 'ORGANIZATION NAME' organization can access the actions and reusable workflows in this repository. Access is allowed only from private repositories.
-
Click Save to apply the settings.
Configuring the retention period for GitHub Actions artifacts and logs in your repository
You can configure the retention period for GitHub Actions artifacts and logs in your repository.
By default, the artifacts and log files generated by workflows are retained for 90 days before they are automatically deleted. You can adjust the retention period, depending on the type of repository:
- For public repositories: you can change this retention period to anywhere between 1 day or 90 days.
- For private repositories: you can change this retention period to anywhere between 1 day or 400 days.
When you customize the retention period, it only applies to new artifacts and log files, and does not retroactively apply to existing objects. For managed repositories and organizations, the maximum retention period cannot exceed the limit set by the managing organization or enterprise.
You can also define a custom retention period for a specific artifact created by a workflow. For more information, see "Removing workflow artifacts."
Setting the retention period for a repository
-
On GitHub, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the left sidebar, click Actions, then click General.
-
Under Artifact and log retention, enter a new value.
-
Click Save to apply the change.