Remove cluster group and subscription overrides for stress test release#2416
Remove cluster group and subscription overrides for stress test release#2416benbp merged 3 commits intoAzure:mainfrom
Conversation
|
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: |
e5f7679 to
8c9dc77
Compare
|
/check-enforcer override |
|
The following pipelines have been queued for testing: |
|
/check-enforcer reset |
|
/check-enforcer evaluate |
| @@ -6,12 +6,9 @@ parameters: | |||
| - name: Environment | |||
| type: string | |||
There was a problem hiding this comment.
It is working like enum.
I think they support enum type.
https://github.com/MicrosoftDocs/azure-devops-docs-pr/blob/master/docs/pipelines/yaml-schema.md#schema-13
There was a problem hiding this comment.
The docs are kind of confusing, I think. This IS an enum, but you don't declare it by specifying enum you declare it by specifying an enum data type which in this case is string, and the values are the enum variants.
| ${{ if eq(parameters.Environment, 'prod') }}: | ||
| azureSubscription: Azure SDK Test Resources | ||
| ${{ if eq(parameters.Environment, 'test') }}: | ||
| azureSubscription: Azure SDK Developer Playground |
There was a problem hiding this comment.
Should test be playground? Should it be a test sub or should we change this to playground env? Maybe this should be called playground and the other one should be called test.
There was a problem hiding this comment.
I think test implies that is a resource used for testing, whereas prod implies a resource used for workloads that aren't touched directly and have more stability. Azure SDK Test Resources has the word "test" but we treat it as a "production" resource for testing workloads. So I'd be more inclined to keep the subscriptions the same, but call the environments prod and playground as that's probably clearer to developers using the scripts. @richardpark-msft thoughts?
There was a problem hiding this comment.
I definitely like renaming "test" to "playground" but I'm still not sure I follow the name "prod", which generally implies to me production vs staging. However I don't care much as long as docs call out what it means... where are the docs? :)
There was a problem hiding this comment.
Per env docs are located here (anchor link to prod): https://github.com/Azure/azure-sdk-tools/blob/main/tools/stress-cluster/cluster/README.md#prod-cluster
There was a problem hiding this comment.
For test -> playground, I'd like to do this in a separate phase since we'll want to rotate the cluster as well and spin people's workloads down from the current one. So I'd prefer to merge this as is and then track the rename via #2493.
|
@weshaggard bump |
weshaggard
left a comment
There was a problem hiding this comment.
Left some feedback on the naming but otherwise seems fine.
|
Hello @azure-sdk! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
The Azure Pipelines UI marks parameters that default to an empty string as "Required" which defeats the whole purpose of
having empty defaults. The overrides are only there as an option for people to use the pipeline for custom dev
environments. Since I think this scenario is pretty rare, I'm just going to remove support for it (you can still
deploy to custom dev environments via the same underlying scripts). Instead, this change simplifies the parameters
to have an environment drop-down that shows you all options to pick from.