Use platform-matrix for Installer jobs

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood

[dagood]

For a few bits of #749:

• Use more conditions rather than top-down assignment when assigning skipTests, publicRidAgnosticPackages, etc. #705 (comment)

• Make the installer matrix accept a set of platforms rather than a set of skips. Maybe merge into platform-matrix? #705 (comment)

In this PR, I made minimal changes to root pipelines to avoid conflicts. (I had a fuller PR a while ago, but when I resurrected the branch I reapplied it manually because things had changed significantly. Keeping it small this time!)

[dagood]

I'm opening this for review tentatively. I don't fully expect CI to pass right now given the Helix issue, but I'm pretty certain about the fix for the only bug I saw in the first PR run. (Some libraries tests also failed, but I don't expect that to be related.) I'm also trying an official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=481636&view=results.

[safern]

the installer azure-pipelines.yml file will go away with the single pipeline effort, so the platform-multijob.yml might no longer be used, but I'll see if it simplifies runtime.yml when including this change in my PR. I like the idea, it definitely simplifies the yml and avoids a lot of duplication in between platforms.

[dagood]

Yeah, decided to add that when the migration to the normal platform matrix brought the number of platform list duplicates from 2 to 3. Doesn't seem like a huge maintainability issue though, either way.

[dagood]

@safern we talked about including this in #1473, but since this is green and you'll need to respin CI on #1473 anyway once conflicts are resolved, going ahead with this merge.

[safern]

Thanks @dagood