-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environments do not get provisioned for repositories set to internal or private #623
Labels
bug
Something isn't working
Comments
Thanks we have the same bug too and we are using GitHub SaaS.
|
The error is fixed after granting Actions read permission to the app. This is the requirement for using this listing endpoint. https://docs.github.com/en/rest/deployments/environments?apiVersion=2022-11-28#list-environments
|
Brad-Abrams
added a commit
to RBC/github-safe-settings
that referenced
this issue
Jun 26, 2024
Addresses issue: [Environments do not get provisioned for repositories set to internal or private github#623](github#623) Adds documentation for permissions required for safe-settings when Environments are used [List Environments](https://docs.github.com/en/rest/deployments/environments?apiVersion=2022-11-28#list-environments) API requires: ``` The fine-grained token must have the following permission set: "Actions" repository permissions (read) ``` [Create an environment variable](https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28#create-an-environment-variable) API requires: ``` The fine-grained token must have the following permission set: "Variables" repository permissions (write) and "Environments" repository permissions (write) ``` With permissions added, issue 623 was resolved.
decyjphr
pushed a commit
that referenced
this issue
Aug 15, 2024
* decompose unit tests, patch sync for environments * remove logging, combine loops as per review comments * Add NopCommand, log.error, and errors * Allow concise config for Environments This commit combines PR [616](#616) and [646](#646) environments.js Add defensive code to prevent the GitHub API from being called with undefined data. In the UI, and API an environment can be added with just an name. Now, safe-settings permits this as well. In the UI, and API an environment can be added without variables. Now, safe-settings permits this as well. In the UI, and API an environment can be added without deployment_protection_rules. Now, safe-settings permits this as well. environments.test.js Add a test case for the scenario when there are zero existing environments Add a test case for an environment name change Add a test case inspired by PR 616 which adds 7 new environments with various attributes Move expect statements out of aftereach() as there is now variability in what is expected across test cases. Specifically, when there is no existing environment, that environment should NOT be queried for variables nor deployment_protection_rules * Update documentation: Environments permissions. Addresses issue: [Environments do not get provisioned for repositories set to internal or private #623](#623) Adds documentation for permissions required for safe-settings when Environments are used [List Environments](https://docs.github.com/en/rest/deployments/environments?apiVersion=2022-11-28#list-environments) API requires: ``` The fine-grained token must have the following permission set: "Actions" repository permissions (read) ``` [Create an environment variable](https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28#create-an-environment-variable) API requires: ``` The fine-grained token must have the following permission set: "Variables" repository permissions (write) and "Environments" repository permissions (write) ``` With permissions added, issue 623 was resolved.
admtorgst
pushed a commit
to helse-sorost/safe-settings
that referenced
this issue
Sep 14, 2024
* decompose unit tests, patch sync for environments * remove logging, combine loops as per review comments * Add NopCommand, log.error, and errors * Allow concise config for Environments This commit combines PR [616](github#616) and [646](github#646) environments.js Add defensive code to prevent the GitHub API from being called with undefined data. In the UI, and API an environment can be added with just an name. Now, safe-settings permits this as well. In the UI, and API an environment can be added without variables. Now, safe-settings permits this as well. In the UI, and API an environment can be added without deployment_protection_rules. Now, safe-settings permits this as well. environments.test.js Add a test case for the scenario when there are zero existing environments Add a test case for an environment name change Add a test case inspired by PR 616 which adds 7 new environments with various attributes Move expect statements out of aftereach() as there is now variability in what is expected across test cases. Specifically, when there is no existing environment, that environment should NOT be queried for variables nor deployment_protection_rules * Update documentation: Environments permissions. Addresses issue: [Environments do not get provisioned for repositories set to internal or private github#623](github#623) Adds documentation for permissions required for safe-settings when Environments are used [List Environments](https://docs.github.com/en/rest/deployments/environments?apiVersion=2022-11-28#list-environments) API requires: ``` The fine-grained token must have the following permission set: "Actions" repository permissions (read) ``` [Create an environment variable](https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28#create-an-environment-variable) API requires: ``` The fine-grained token must have the following permission set: "Variables" repository permissions (write) and "Environments" repository permissions (write) ``` With permissions added, issue 623 was resolved.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem Description
When managing environments with safe settings, if the repository is set to public, safe settings will create all environments defined within the suborg configuration. If the repository visibility is set to private or internal, safe settings presents an error even though the provisioning of environments has been tested for all repository visibilities via the REST API.
What is actually happening
If the repositories are anything but public visibility, safe settings cannot provision the environments.
What is the expected behavior
Safe Settings should be able to manage environments on repositories that are set to private or internal visibility.
Error output, if available
Context
We had initially opened #611 regarding environment provisioning but assumed the issue was due to insufficient licensing for the non-prod environments but after deploying to production, the environment provisioning would still only work for public repositories.
Using the REST API, we can successfully create environments for repositories even if the repository is set internal or private visibility. We are wondering why Safe settings specifically returns an error for environments that are being provisioned against internal or private repositories.
Create environment for a public repository
response
Create an environment for an internal repository
response
Create an environment for a private repository
response
Environments suborg configuration
Are you using the hosted instance of probot/settings or running your own?
Running safe settings on AKS with ingress for webhook.
If running your own instance, are you using it with github.com or GitHub Enterprise?
GitHub Enterprise Server
Version of probot/settings
Running Probot v12.3.3 (Node.js: v16.20.2)
Version of GitHub Enterprise
GitHub Enterprise Server 3.11
The text was updated successfully, but these errors were encountered: