Downloads the Cargo tools from an Azure pipeline using a YAML step
template.
This resolves a problem in commit 69f6e96 that was not found until
after check-in due to the nature of the issue. It is summarized
below.
In the original check-in (69f6e96), the following succeeds and fails:
Downloading and Caching as an Artifact:
✓ Use GitHub REST API to download release and extract the binaries
✓ Publish the binaries as a pipeline artifact in the projectmu org
Retrieving the Artifact
Note: In all cases, try the DownloadPipelineArtifact@2 and
DownloadBuildArtifacts@1 tasks
✓ Access in a manually triggered pipeline
✓ Access in a PR triggered pipeline from a branch in the microsoft
org repo (i.e. not a fork)
✗ Access in a PR triggered pipeline from a branch outside the
microsoft org repo (i.e. a fork)
To allow testing using pre-existing PR check pipelines (which have
access to branches on the microsoft org, not forks), the last case
was unexpected and not encountered until the PRs completed.
Since the information is readily available using the Azure Pipelines
REST API without authentication, this change replaces the built-in
tasks with calls to download the binaries from the REST API.
There's a few quirks with pipelines that are accounted for:
The Python code is inline so it can directly be used as a
template in other YAML files that are used as a repository resource.
If in a separate Python file, the mu_devops repo would need to be
checked out to use access the file. Checking out the repo would
increase build times and complicate pre-existing logic.
The Azure Pipeline InvokeRESTAPI@1 task is not used as it is
limited to agentless jobs.
Conditions are not allowed on templates. Therefore the OS condition
is moved to a string parameter that is compared in the condition
on the task in the template. By default, the task will run on all
operating systems if not specified.
As a follow up, I will explore the Cache@2 task which might simplify
some logic but require changes elsewhere as an alternative to cache
the binaries in the pipelines.
Downloads the Cargo tools from an Azure pipeline using a YAML step template.
This resolves a problem in commit 69f6e96 that was not found until after check-in due to the nature of the issue. It is summarized below.
In the original check-in (69f6e96), the following succeeds and fails:
DownloadPipelineArtifact@2andDownloadBuildArtifacts@1tasksTo allow testing using pre-existing PR check pipelines (which have access to branches on the microsoft org, not forks), the last case was unexpected and not encountered until the PRs completed.
Since the information is readily available using the Azure Pipelines REST API without authentication, this change replaces the built-in tasks with calls to download the binaries from the REST API.
There's a few quirks with pipelines that are accounted for:
InvokeRESTAPI@1task is not used as it is limited to agentless jobs.conditionon the task in the template. By default, the task will run on all operating systems if not specified.As a follow up, I will explore the
Cache@2task which might simplify some logic but require changes elsewhere as an alternative to cache the binaries in the pipelines.Signed-off-by: Michael Kubacki michael.kubacki@microsoft.com