Use Arcade's publishing logic to publish a given VMR vertical #47076
Conversation
… for a given vertical instead of having custom tasks
ghost
added
the
…ome root utility project. This build, however, only publishes the assets. Unlike the approach I take in dotnet#47076, this approach allows our final "vertical" publish to use a the live Arcade logic instead of the bootstrapping Arcade.
…ment that's causing problems
|
/azp run sdk-unified-build |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
|
Retargeted to release/10.0.1xx-preview4. Official build at https://dev.azure.com/dnceng/internal/_build/results?buildId=2693317&view=results. Once the linked build is green, I can merge it in (and then it'll flow back to main in the standard SDK codeflow). |
|
In the latest build, |
|
I think I figured it out. The vertical manifests are expected to have the VerticalName attribute on them (that's how JoinVerticals knows the vertical an item is from). New official build here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2693958&view=results |
|
The latest issue appears to be that there are assets that are duplicated between verticals. These are PDBs. Two/three possible ideas:
|
|
Looks like that didn't quite do it...it looks like the PhaseName didn't make it into the artifact names |
|
Last issue appears that the PDBs are getting flattened in the final join, which we don't want. |
mmitche
merged commit bf04e12
into
dotnet:release/10.0.1xx-preview4
5 participants
Instead of having our own custom targets and tasks to publish a given VMR vertical, use the tooling in the Arcade SDK to publish a vertical.
Contributes to dotnet/arcade#15317
Depends on a bootstrap Arcade SDK containing dotnet/arcade#15572