Use latest tag for release

[pauldendulk]

No description provided.

[pauldendulk]

@janusw You used git describe --tags to publish the latest nugets which looked like a nice solution so I now use git describe --tags --abbrev=0 to get the version. A requirement is that we set the new version tag before the release.

[janusw]

Makes sense I guess 👍

There general idea with this workflow is that it never runs automated, but you'd run it manually on a tagged version, in order to push the pkg to nuget.org, right?

The only problem might be that one can forget to set (or push) the tag or run the workflow on a non-tagged commit, which then looks like it was the actual tag.

As an alternative one could possibly check whether we're actually running on a tagged version (by checking if git describe --tags --abbrev=0 is the same as git describe --tags), and abort if this is not the case. Would this be a good idea?

[pauldendulk]

There general idea with this workflow is that it never runs automated, but you'd run it manually on a tagged version, in order to push the pkg to nuget.org, right?

That is the way it was intended. A downside of that approach could be that the script is not tested on regular builds it fails once used on release (in the current situation there are not many ways it could fail because everything is still quite simple, but this often occurs when a project becomes more complex). A better approach would be to make the publishing a manual step of build.yml. Perhaps release_nuget parameter could be optional and could be used to determine how we set the the version string.

The only problem might be that one can forget to set (or push) the tag or run the workflow on a non-tagged commit, which then looks like it was the actual tag.

As an alternative one could possibly check whether we're actually running on a tagged version (by checking if git describe --tags --abbrev=0 is the same as git describe --tags), and abort if this is not the case. Would this be a good idea?

But we already have older tags in our master, so I assume an old version will be returned (but perhaps I do not understand you) and everything will work correctly until it tries to push to nuget (because you can not overwrite an existing version).

[janusw]

The only problem might be that one can forget to set (or push) the tag or run the workflow on a non-tagged commit, which then looks like it was the actual tag.
As an alternative one could possibly check whether we're actually running on a tagged version (by checking if git describe --tags --abbrev=0 is the same as git describe --tags), and abort if this is not the case. Would this be a good idea?

But we already have older tags in our master, so I assume an old version will be returned

Yes, true.

(but perhaps I do not understand you) and everything will work correctly until it tries to push to nuget (because you can not overwrite an existing version).

Ah, I have never actually tried overwriting with nuget.org, but it's certainly good that this is forbidden :)

So, all good. The workflow will anyway work well as long as it's used wisely 😁