Compute the package version from the git tags instead of nuget.org

[meziantou]

What

The compute_package_version job of the CI computed the version of the next package by querying nuget.org for the latest published version. It now derives it from the git tags.

Why

The create_release job already creates a tag named after the version for every published package, so the tags are an equally accurate source, and computing a version no longer requires nuget.org to be reachable.

How

• The job now checks out the repository (it previously had no checkout step) with fetch-depth: 0 so that all the tags are fetched, and filter: tree:0 to keep the clone cheap by skipping the file contents.
• The script takes the greatest 3.0.N tag and increments it. It fails with an ::error:: annotation when no matching tag is found, instead of silently computing 3.0.1.

Why not fetch-tags: true

That would be cheaper, but it is not reliable here. actions/checkout implements the flag by dropping --no-tags, which leaves git's tag auto-following, and under the default shallow fetch that only brings the tags pointing at the fetched commit. Tested against this repository, it fetched exactly one tag; on a PR branch, or on main once a commit lands after the last release, it would have fetched none and the job would have failed. The all-history refspec includes +refs/tags/*:refs/tags/* explicitly, which fetches all 481 tags.

Testing

The run block was extracted from the YAML and executed with pwsh against the real tags of the repository:

Case	Result
refs/heads/main	3.0.184
Pull request ref	3.0.184-build.<run_id>
Repository without tags	Error annotation, exit 1

The previous nuget.org based logic, run side by side, also yields 3.0.184, so the two agree. The workflow file still parses and all its jobs are intact.

Note for the reviewer

The source of truth for the version moves from "what is published on nuget.org" to "what create_release tagged". The two can diverge if deploy succeeds but create_release fails: the next run would recompute the same version and dotnet nuget push --skip-duplicate would quietly skip the push instead of failing. The window is narrow, as the tag is created right after the deploy, but it did not exist before. Moving the tag creation before the push would close it, if that is worth doing.