skarpdev / dotnet-version-cli

dotnet version cli (similar to npm version cli)
MIT License
38 stars 12 forks source link

Support for VersionPrefix and VersionSuffix Tags #102

Open jberude opened 1 year ago

jberude commented 1 year ago

We are using the Microsoft.NET.Build.Containers package to containerize and push our applications. The image tag is the version from csproj-File. As we need to provide images for multiple architectures we need to deploy multiple tags and build corresponding manifests.

e.g. Version 1.0.1 results in tags 1.0.1-x64 and 1.0.1-arm64 with a docker manifest for 1.0.1 combining those tags.

We aligned with Microsoft Versioning documentation to build the application and provide the Application Version in <VersionPrefix> in csproj and the Suffix in Command-Line resulting in the expected Version.

dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -p:ContainerRegistry=${{ secrets.ACR_ENDPOINT }} -p:VersionSuffix=x64

See more details on versioning in Blogpost from Andrew Lock.

Unfortunately the dotnet-version-cli does not support Tags <VersionPrefix> and <VersionSuffix>. This would be super helpful to be in line with official csproj-features.

First look at Skarp.Version.Cli.CsProj.ProjectFileProperty points out the missing entries.

Many Thanks for this great project!!!

nover commented 1 year ago

Thanks for using the tool and your detailed issue!

I think I need to understand your use case a bit more in depth before I can make changes. How exactly is you desire that dotnet-version-cli plays along with your arch releases? If I understood you correctly, I would assume that it's OK that dotnet-version-cli tags up a release like 1.0.1, which would be the official Docker tag too? And there are the underlying arch specific tags.

Let me know 😊

jberude commented 1 year ago

Sure. Let me phrase the use case.

From what I have read to csproj-Version structure is {VersionPrefix}-{VersionSuffix} = {Version}

When release our application we need to build multiple docker images for multiple architectures (x64, arm64). These images must be tagged accordingly, so after releasing version 1.0.1 we get the docker images

and a 1.0.1 manifest combining these images.

We have solved this by using the VersionPrefix-Tag:

<VersionPrefix>1.0.1</VersionPrefix>

And releasing with Microsoft.NET.Build.Containers using following commands:

 dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -p:ContainerRegistry=${{ secrets.ACR_ENDPOINT }} -p:VersionSuffix=x64
  dotnet publish --os linux --arch arm64 -p:PublishProfile=DefaultContainer -p:ContainerRegistry=${{ secrets.ACR_ENDPOINT }} -p:VersionSuffix=arm64

After those images have been created we now need to build the docker manifest. But we need the corresponding version number.

docker manifest create {IMAGE_NAME}:{VERSION} \
--amend {IMAGE_NAME}:{VERSION}-arm64 \
--amend {IMAGE_NAME}:{VERSION}-x64 \

To do so we need to extract (and increase) the version from the VersionPrefix-Tag. If the dotnet-version-cli tool could provide necessary functionality. I would be very happy to contribute.

Get Version

csproj-File:

<VersionPrefix>1.0.1</VersionPrefix>

Command:

$ dotnet version
dotnet-version-cli
Project version is:
        1.0.1

Set Version

csproj-File:

<VersionPrefix>1.0.1</VersionPrefix>

Command:

$ dotnet version minor

csproj-File:

<VersionPrefix>1.0.2</VersionPrefix>
nover commented 1 year ago

Okay @jtrebschuh - I think I understand your use case now.

It basically boils down to supporting / using the VersionPrefix in dotnet-version-cli.

I guess the simplest approach would be to try and detect the version fields used by the csproj or common props file. And perhaps add the long awaited config support to allow tweaking this: #9

If you're up for trying to provide a PR it would be awesome, otherwise I'll have a look at it in the coming weeks