Repository navigation
Conversation
|
@phmonte we really need your help here 🙏 |
|
@badcel Can you resolve the merge conflicts? |
|
I think I could but if nuget trusted publishing is not set up it makes no sense. Then I'm rebasing this PR regularly without the commitment of the official owner that it will be useable at all. |
|
How about we publish a version to feedz.io while we try to sort out the nuget.org credentials. |
|
I just released a version with the latest implementations. @badcel , thank you very much for your contribution. Currently, the project uses APICompat. In this case, we need to think of a solution to keep it working and to allow us to identify/parameterize in the pipeline when we want to generate a version, even with break-changes. What do you think? @Corniel and @slang25. I can add them to azure-devops in the meantime. Currently, the trigger is working correctly; I just made some changes to the current pipeline to generate new versions. The new version of ubuntu-latest didn't allow the use of existing service connections. |
|
The pipeline has a field "Version Suffix" of type string which can be filled before starting the pipeline manually. You can do the same with a Boolean value to influence some tools which run during the release process. I can rebase the PR if desired but don't have the capacity to add new steps to it. If you want to include new steps please do it after merging or feel free to push updates to my branch. Whatever suits you best. |
598a5b1 to
eb0f763
Compare
eb0f763 to
16931e2
Compare
|
I rebased the PR and added dotnet 10 support. |
|
The error looks unrelated to my changes I think? |
|
Is this one stale? |
|
@badcel Time to have a look? |
4 participants
Add Release pipeline
This would be the "idea" of the pipeline. I'm not sure if the building will work. Locally I got errors related to net6.0 which is not installed in the pipeline currently (but it is not installed in the already present build workflow, too).
The version number is defined in the
Directory.Build.propsfile for reproducability. So if one checks the nuget package for the originating commit and does agit checkoutfor it, the produced nuget should be identical to the one from nuget.org. So you would need to bump the version before a new release.The pipeline allows to define some "version suffix" like "preview.1" which would automatically result in a nuget package versioned for example like "7.1-preview.1".
I enabled continuousintegrationbuild as I understand that it shoud be set for official releases.
I never used nuget trusted publishing myself (I still use api keys for my projects). But there is some configuration needed. See the linked documentation.
Fixes: #323