Workaround AzDo issue when evaluating Build.SourcesDirectory variable in a docker container

[safern]

Since we don't know how long it is going to take for a fix to roll out from AzDo use a workaround they suggested for issue: #1967

We can revert this change once their fix rolls out.

[trylek]

LGTM

[dagood]

Does this work when passed as a task arg? ${...} is a shell scripting syntax, not known by cmd or AzDO as far as I know.

runtime/eng/pipelines/common/download-artifact-step.yml

Lines 18 to 23 in f991fe7

	# Unzip artifact
	- task: ExtractFiles@1
	displayName: 'Unzip ${{ parameters.displayName }}'
	inputs:
	archiveFilePatterns: $(Build.SourcesDirectory)/__download__/${{ parameters.artifactName }}/${{ parameters.artifactFileName }}
	destinationFolder: ${{ parameters.unpackFolder }}

[dagood]

Looks like not, macOS is choking:

/usr/bin/tar -xvf /Users/runner/runners/2.164.3/work/1/s/__download__/CoreCLRProduct_OSX_x64_release/CoreCLRProduct_OSX_x64_release.tar.gz -C /Users/runner/runners/2.164.3/work/1/s/${_CORECLRDOWNLOADPATH}
https://dev.azure.com/dnceng/public/_build/results?buildId=491593&view=logs&j=165846b8-a05f-59ec-06e6-141fc8c9f9e4&t=f25ddc43-e446-5261-e436-e8dc261f76c0&l=13

Then fails during the build trying to use /Users/runner/runners/2.164.3/work/1/s/artifacts/transport/coreclr.

[dagood]

I think a workaround might be to run a script step on the affected Linux platforms that uses an AzDO command to reset the value of _coreClrDownloadPath to ${_CORECLRDOWNLOADPATH}, then maybe we can continue to use $(_coreClrDownloadPath) in subsequent steps as normal.

[safern]

Or just use this directly in the declaration of the variable, instead of here... also we could condition that to use this syntax if container != ''

[safern]

For some reason I thought it was a yaml syntax thing. I just pushed a commit that only uses this in the _coreClrArtifactsPathArg declaration and when container != ''

[safern]

All the build legs are green and all the tests that ran are green. Will merge to unblock other PRs.