Bugfix/no support of wildcard directly #12
Conversation
… i edited the command, to first retrieve the most recent nupkg package using Get-ChildItem which supports wildcards, and then push the result
|
@matt-lethargic This merge request should fix the release part. (hopefully) |
.github/workflows/release.yml
Outdated
| run: | |
There was a problem hiding this comment.
Do we not already have the version number to enable us to build the correct file name to use with nuget push?
There was a problem hiding this comment.
And nuget push should work with wildcards as I do it for my day job: https://github.com/Nexmo/github-actions/blob/main/nuget-release/index.js
There was a problem hiding this comment.
You are completely right. We do have the version number, and in theory the wildcard should not be needed.
Arh and i see, i just read around and it seemed like PowerShell didn't have as good wildcard support as bash, and the error was this.
So it seemed like the wildcard was taken as the path itself.
Should i fix the wildcard, or should i just bind to the actual nuget package directly.
What's your thought?
There was a problem hiding this comment.
Personally I'd use the exact path using the version number if possible. But it's entirely up to you. If it works, it works.
There was a problem hiding this comment.
Yes, that seems like the best solution.
I will fix it.
The dotnet nuget push command does not allow wildcards.
I updated the release action with some powershell code, that will function the same way as I expect the wildcard was meant to function.
It uses Get-ChildItem to find the nuget package, and pushes the top 1 result.
Tested on my own fork, and it seems like it finds the correct package, but have not tested the nuget push itself.