Publishing V3 doesn't preserve Category metadata in merged manifest

• This issue is blocking
• This issue is causing unreasonable pain

In diagnostics we recently moved to V3 Publishing. We set a special target in publishing.props to generate add a nupkg to ItemsToPushToBlobFeed with the ManifestArtifactData having Category=OTHER. The resulting manifest having a Category attribute in the manifest, and the package would get published to blob storage. However, V3 publishing doesn’t preserve such metadata when generating MergedManifest.xml (The Blob class in arcade-services doesn’t have a field for it) and the item ends up in the feed assigned to the default channel. This causes it to not be available through an aka.ms link nor in blob storage, and we use this in the dotnet-docker repo to generate the images. Is there any way to get this back in v3, or is this expected?

cc: @jander-msft

[epananth]

changes merged. Closing this one finally ! 😃

[MichaelSimons]

It means that a new build of a docker image could easily be non-deterministic.

The latest link is just being used by the update automation to determine what the latest version is so that the Dockerfile can be updated accordingly. The Dockerfiles themselves reference static versions.

dotnet/monitor Dockerfile snippet

# Install .NET Monitor
ENV DOTNET_MONITOR_VERSION=5.0.0-preview.3.20523.1
RUN wget -O dotnet-monitor.$DOTNET_MONITOR_VERSION.nupkg https://dotnetcli.azureedge.net/dotnet/diagnostics/monitor5.0/dotnet-monitor.$DOTNET_MONITOR_VERSION.nupkg \
    && dotnetmonitor_sha512='86936df6ff763d5eceba18490dd1a745d7cf8b84a0999a408415bdfb35c687dc023caa5eb66cbea09a33065f36470400f09be3d7456de80911a87415aaaadc01' \
    && echo "$dotnetmonitor_sha512  dotnet-monitor.$DOTNET_MONITOR_VERSION.nupkg" | sha512sum -c - \
    && dotnet tool install dotnet-monitor --tool-path /app --add-source / --version $DOTNET_MONITOR_VERSION --no-cache \
    # To reduce image size, remove the copy of the nupkg under the tools.
    && find /app -print | grep -i '.*[.]nupkg$' | xargs rm \
    && rm dotnet-monitor.$DOTNET_MONITOR_VERSION.nupkg

Could we constrain the update in such a way that the dockerfiles can be easily manipulated by Maestro?

I will schedule a meeting to discuss this further post 5.0 release.