Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.github.com/actions/reference/environments below:

Managing environments for deployment - GitHub Docs

You can create environments and secure those environments with deployment protection rules. A job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.

Environments, environment secrets, and deployment protection rules are available in public repositories for all current GitHub plans. They are not available on legacy plans, such as Bronze, Silver, or Gold. For access to environments, environment secrets, and deployment branches in private or internal repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise. If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, other deployment protection rules, such as a wait timer or required reviewers, are only available for public repositories.

Note

Users with GitHub Free plans can only configure environments for public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.

Organizations with GitHub Team and users with GitHub Pro can configure environments for private repositories. For more information, see GitHub’s plans.

• For general information about environments, see Deploying with GitHub Actions.
• For information about available rules, see Deployments and environments.

To configure an environment in a personal account repository, you must be the repository owner. To configure an environment in an organization repository, you must have admin access.

Note

• Creation of an environment in a private repository is available to organizations with GitHub Team and users with GitHub Pro.
• Some features for environments have no or limited availability for private repositories. If you are unable to access a feature described in the instructions below, please see the documentation linked in the related step for availability information.

1. On GitHub, navigate to the main page of the repository.

2. Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

3. In the left sidebar, click Environments.

4. Click New environment.

5. Enter a name for the environment, then click Configure environment. Environment names are not case sensitive. An environment name may not exceed 255 characters and must be unique within the repository.

6. Optionally, specify people or teams that must approve workflow jobs that use this environment. For more information, see Deployments and environments.

   1. Select Required reviewers.
   2. Enter up to 6 people or teams. Only one of the required reviewers needs to approve the job for it to proceed.
   3. Optionally, to prevent users from approving workflows runs that they triggered, select Prevent self-review.
   4. Click Save protection rules.

7. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed. For more information, see Deployments and environments.

   1. Select Wait timer.
   2. Enter the number of minutes to wait.
   3. Click Save protection rules.

8. Optionally, disallow bypassing configured protection rules. For more information, see Deployments and environments.

   1. Deselect Allow administrators to bypass configured protection rules.
   2. Click Save protection rules.

9. Optionally, enable any custom deployment protection rules that have been created with GitHub Apps. For more information, see Deployments and environments.

   1. Select the custom protection rule you want to enable.
   2. Click Save protection rules.

10. Optionally, specify what branches and tags can deploy to this environment. For more information, see Deployments and environments.

    1. Select the desired option in the Deployment branches dropdown.

    2. If you chose Selected branches and tags, to add a new rule, click Add deployment branch or tag rule

    3. In the "Ref type" dropdown menu, depending on what rule you want to apply, click Branch or Tag.

    4. Enter the name pattern for the branch or tag that you want to allow.

       Note

       Name patterns must be configured for branches or tags individually.

    5. Click Add rule.

11. Optionally, add environment secrets. These secrets are only available to workflow jobs that use the environment. Additionally, workflow jobs that use this environment can only access these secrets after any configured rules (for example, required reviewers) pass. For more information, see Deployments and environments.

    1. Under Environment secrets, click Add Secret.
    2. Enter the secret name.
    3. Enter the secret value.
    4. Click Add secret.

12. Optionally, add environment variables. These variables are only available to workflow jobs that use the environment, and are only accessible using the vars context. For more information, see Deployments and environments.

    1. Under Environment variables, click Add Variable.
    2. Enter the variable name.
    3. Enter the variable value.
    4. Click Add variable.

You can also create and configure environments through the REST API. For more information, see REST API endpoints for deployment environments, REST API endpoints for GitHub Actions Secrets, REST API endpoints for GitHub Actions variables, and REST API endpoints for deployment branch policies.

Running a workflow that references an environment that does not exist will create an environment with the referenced name. If the environment is created from running implicit page builds (for example, from a branch or folder source), the source branch will be added as a protection rule to the environment. Otherwise, the newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.

To configure an environment in a personal account repository, you must be the repository owner. To configure an environment in an organization repository, you must have admin access.

Deleting an environment will delete all secrets and protection rules associated with the environment. Any jobs currently waiting because of protection rules from the deleted environment will automatically fail.

1. On GitHub, navigate to the main page of the repository.

2. Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

3. In the left sidebar, click Environments.

4. Next to the environment that you want to delete, click .

5. Click I understand, delete this environment.

You can also delete environments through the REST API. For more information, see REST API endpoints for repositories.

When a workflow job that references an environment runs, it creates a deployment object with the environment property set to the name of your environment. As the workflow progresses, it also creates deployment status objects with the environment property set to the name of your environment, the environment_url property set to the URL for environment (if specified in the workflow), and the state property set to the status of the job.

You can access these objects through the REST API or GraphQL API. You can also subscribe to these webhook events. For more information, see REST API endpoints for repositories, Objects (GraphQL API), or Webhook events and payloads.

GitHub Actions provides several features for managing your deployments. For more information, see Deploying with GitHub Actions.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4