chore: select enabled environments on project creation #6869
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
thomasheartman
commented
Apr 16, 2024
thomasheartman
commented
Apr 16, 2024
|
Oh, and the tests will fail until the flag has been added |
Tymek
approved these changes
Apr 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds functionality to the
createProjectfunction to choose which environments should be enabled when you create a new project. The newenvironmentsproperty is optional and omitting it will make it work exactly as it does today.The current implementation is fairly strict. We have some potential ideas to make it easier to work with, but we haven't agreed on any yet. Making it this strict means that we can always relax the rules later.
The rules are (codified in tests):
environmentsis not provided, all non-deprecated environments are enabledenvironmentsis provided, only the environments listed are enabled, regardless of whether they're deprecated or notenvironmentsis provided and is an empty array, the service throws an error. The API should dilsallow that via the schema anyway, but this catches it in case it sneaks in some other way.environmentsis provided and contains one or more environments that don't exist, the service throws an error. While we could ignore them, that would lead to more complexity because we'd have to also check that the at least one of the environments is valid. It also leads to silent ignoring of errors, which may or may not be good for the user experience.The API endpoint for this sits in enterprise, so no customer-facing changes are part of this.