Add config for 1ES hosted Linux pool. #17472
Conversation
|
/azp run net - core - ci |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run net - core - ci |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run net - core - ci |
|
Azure Pipelines successfully started running 1 pipeline(s). |
d4f1ae3 to
1fe0daa
Compare
|
/azp run net - core - ci |
|
Azure Pipelines failed to run 1 pipeline(s). |
|
/azp run net - storage - tests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
This is now ready to merge. It doesn't appear to break live testing at all and its running successfully on Linux agents. |
|
/azp run net - storage - tests |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| OSVmImage: # "windows-2019" # Comment back in to swap back to public hosted pool. | ||
| TestTargetFramework: netcoreapp2.1 | ||
| CollectCoverage: true | ||
| Windows_NetCoreApp_ProjectReferences: | ||
| Pool: azsdk-pool-mms-win-2019-general # Comment out to swap back to public hosted pool. | ||
| Pool: ${{ parameters.WindowsPool }} # Comment out to swap back to public hosted pool. | ||
| OSVmImage: # "windows-2019" # Comment back in to swap back to public hosted pool. |
There was a problem hiding this comment.
At what point do we think we should remove these empty properties? As for my other comment about could we control these at the higher level I guess we could have 2 parameters that we treat as mutually exclusive WindowsPool and WindowsImage and we can just have one be empty and the other set in order to toggle between these 2 if we need that functionality.
There was a problem hiding this comment.
Also we need to figure out how we want to handle the verify-agent-os templates when we start to run with a larger matrix. Personally I think it is even more important to ensure we are running the expected agent now that we are going to be swapping around pools.
* Add config for 1ES hosted Linux pool.
This PR does two things:
azsdk-pool-mms-win-2019-generalazsdk-pool-mms-ubuntu-1804-generalThe convention that I'm using here should be fairly self explanatory. I'll decommission the old pool as soon as I've confirmed that these ones are working with the PR. I opted to remove the machine sizes from the pool because other than the image we use (which will be selected by changing pool), the VM size is probably the next thing that will change so its not a good idea to put it in the pool name.
I'm also going to be introducing some top-level archetype parameter templates that set these as defaults which will then be overridable.