Adjustments enabling change-specific PackageInfo

[scbedd]

Effectively, this allows Save-Package-Properties to honor the diff file.

In practice it looks like this

todo:

• Do we want to keep ServiceInput or duplicate this thing into another script entirely?
• Remove debugging outputs

On my build phase, this is the yml gating access to the filter

- ${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
    - pwsh: |
        mkdir -p $(Build.ArtifactStagingDirectory)/diff
      displayName: Create PR Diff Folder

    - task: PowerShell@2
      inputs:
        filePath: 'eng/common/scripts/Generate-PR-Diff.ps1'
        arguments: '-TargetPath "$(Build.SourcesDirectory)" -ArtifactPath $(Build.ArtifactStagingDirectory)/diff'
      displayName: 'Generate PR Diff'

    - pwsh: |
        Write-Host "We freshly generated the PR diff, and this is what it sees!"
        Get-ChildItem -R -Force $(Build.ArtifactStagingDirectory)/diff | % { $_.FullName }
        cat $(Build.ArtifactStagingDirectory)/diff/diff.json
      displayName: Dump PR Diff

    - task: Powershell@2
      inputs:
        filePath: $(Build.SourcesDirectory)/eng/common/scripts/Save-Package-Properties.ps1
        arguments: >
          -ServiceInput $(Build.ArtifactStagingDirectory)/diff/diff.json
          -OutDirectory $(Build.ArtifactStagingDirectory)/PackageInfo
        pwsh: true
        workingDirectory: $(Pipeline.Workspace)
      displayName: Save package properties filtered for PR
  - ${{ else }}:
    - task: Powershell@2
      inputs:
        filePath: $(Build.SourcesDirectory)/eng/common/scripts/Save-Package-Properties.ps1
        arguments: >
          -ServiceInput ${{parameters.ServiceDirectory}}
          -OutDirectory $(Build.ArtifactStagingDirectory)/PackageInfo
        pwsh: true
        workingDirectory: $(Pipeline.Workspace)
      displayName: Save package properties for service

Everywhere else that may need to do work against the changeset will get this packages artifact, then utilize it to determine targeted packages

  - ${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
    # if we are in a PR, utilize the fact that the package properties folder will already be downloaded in the Packages folder
    # any json file that exists within the PackagePropertiesFolder will be added to the targeting string
    - pwsh: |
        $packageProperties = Get-ChildItem -Recurse -Force "${{ parameters.PackagePropertiesFolder }}" `
          | Where-Object { $_.Extension -eq '.json' } `
          | Foreach-Object { $_.Name } `
          | ForEach-Object { $_.Replace(".json", "") }

        $setting = $packageProperties -join ","

        Write-Host "Setting TargetingString to $setting"
        Write-Host "##vso[task.setvariable variable=TargetingString;]$setting"
      displayName: Check override of targeting string by variable for PR builds

What this specifically willl vary per language. For Python it's just setting TargetingString variable to a comma separated list of package names.

EDIT: the rebase worked. got through android patch.

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow

[azure-sdk]

The following pipelines have been queued for testing:
java - template
java - template - tests
js - template
net - template
net - template - tests
python - template
python - template - tests
You can sign off on the approval gate to test the release stage of each pipeline.
See eng/common workflow