Dotnet published containers adding ".git" to image source label

[nslusher-sf]

Describe the bug

We are publishing Docker containers with the label org.opencontainers.image.source set so that the packages will be associated with one of our GitHub repositories however this is not currently working in our setup.

We are creating containers using a dotnet publish command outlined in Microsoft documentation here.
Our .csproj file contains the following line: <DockerImageLabels>org.opencontainers.image.source=https://github.com/our-org/our-repo</DockerImageLabels> however when inspecting the resulting image we see that the label value actually gets published by Dotnet as https://github.com/our-org/our-repo.git (note the additional .git at the end of the URL).

GitHub does not see this as a properly formatted tag and our published container is not getting associated with the repository as a result.

To Reproduce

1. Follow instructions in the Microsoft documentation listed in the "Describe the bug" section to set up container publishing for a project.

2. Add an example DockerImageLabels line in a .csproj file:

   <PropertyGroup>
   <TargetFramework>net6.0</TargetFramework>
   ...
   <DockerImageLabels>org.opencontainers.image.source=https://github.com/our-org/our-repo</DockerImageLabels>
   </PropertyGroup>

3. Run a dotnet publish command (we are using this command: dotnet publish --os linux --arch x64 -c Release -p:PublishProfile=DefaultContainer) and observe that the container is created with an org.opencontainers.image.source label that has an additional ".git" extension added to the URL

Exceptions (if any)

Further technical details

• Include the output of dotnet --info

  
  .NET SDK:
  Version:   7.0.404
  Commit:    22f221a24c

Runtime Environment: OS Name: ubuntu OS Version: 22.04 OS Platform: Linux RID: ubuntu.22.04-x64 Base Path: /usr/share/dotnet/sdk/7.0.404/

Host: Version: 7.0.14 Architecture: x64 Commit: 808851b07a

.NET SDKs installed: 7.0.404 °/usr/share/dotnet/sdk§

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.25 °/usr/share/dotnet/shared/Microsoft.AspNetCore.App§ Microsoft.AspNetCore.App 7.0.14 °/usr/share/dotnet/shared/Microsoft.AspNetCore.App§ Microsoft.NETCore.App 6.0.25 °/usr/share/dotnet/shared/Microsoft.NETCore.App§ Microsoft.NETCore.App 7.0.14 °/usr/share/dotnet/shared/Microsoft.NETCore.App§

Other architectures found: None

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

- The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
JetBrains Rider 2023.3.3

[baronfel]

Hi @nslusher-sf - this is because the .NET SDK container targets do not know about the DockerImageLabels property - instead ContainerLabel MSBuild Items are what the tooling expects. The full list of labels we support is here (though we need to update that documentation you linked to to match!).

Where did you see the DockerImageLabels property described? Was it any Microsoft documentation leading you that way?

[baronfel]

Separately, the tooling is inferring the value of this property from the PrivateRepositoryUrl MSBuild property when the PublishRepositoryUrl property is set to true - the first is set by Sourcelink during the build, and the second is defaulted in a variety of situations.

[nslusher-sf]

@baronfel It might have been the documentation here.

I just tried publishing a container using the ContainerLabel property instead of DockerImageLabels and I am still getting the same result - a ".git" extension is added to the value of the label. Is that expected behavior?

[baronfel]

It is expected behavior for this specific label, because we haven't implemented a 'graceful fallback' for it - meaning that we always overwrite any provided value with our own.This is mostly because we didn't think people were likely to be setting this kind of a value, but it's fairly easy to do. We could take this item as an enhancement for the 8.0.300 SDK release, IMO.

[nslusher-sf]

That would be great as I'm not sure if the GitHub team will consider adding support for image source URLs that have the ".git" extension but I will ask.

[baronfel]

@nslusher-sf for my information/prioritization - what's the connection between GitHub and image source urls with the .git suffix?

[nslusher-sf]

We are publishing our containers to GitHub in our CI/CD pipeline using instructions similar to what they have in the docs here except for steps 1-4 we are using dotnet publish to create our container with the image source label. GitHub does not see the URL as valid with the .git suffix and does not associate the containers properly with the target repository.

[baronfel]

Thank you! That makes perfect sense. Thanks for the details on this whole chat so far.

[nslusher-sf]

You're welcome! Thanks for the quick replies.

[baronfel]

As a note for future-Chet I was able to do this association several months ago in the baronfel/sdk-container-demo repository here - but that was so long ago I don't recall if it was automatic or manual.

[nslusher-sf]

@baronfel We did try using the <PackageProjectUrl> property that you have in your .csproj file in ours and we published to GitHub but unfortunately the container did not get associated to the repository. My guess is the association was manual as the GitHub documentation only mentions supporting the org.opencontainers.image.source container label.

[baronfel]

Thanks for the data point - I'm trying to find a contact in the GitHub Container Registry org about how this works to validate.

[baronfel]

I did some digging and many of the other container scanning tools like Snyk show examples/document only using the 'bare' form of the repository url. Since .NET's tooling uses the logs from the git config directly we get the .git-suffixed version:

[remote "origin"]
        url = https://github.com/baronfel/FsAutoComplete.git
        fetch = +refs/heads/*:refs/remotes/origin/*

I think this is something we should patch over in the container tooling, but am talking with the SourceLink team (who populate the properties that we rely on) to determine what the approach should be to be future-proof.

[baronfel]

@tmat - I looked at the SourceLink task and because those retrieve the repo url from git's config it's always in 'expanded' form. Do you have any thoughts or suggestions if there is a more 'user-facing' way to handle this suffix? Do you know if there is a generally-known set of prefixes that we could strip or something?

[baronfel]

I'm going to close this as we merged the linked PR for the 8.0.300 release.