Using commit ids for prerelease tag breaks dependency

[johnwc]

The issue with using git commit ids as prerelease values is that they are not incremental and break the sorting. If a nuget monorepo gets built with a project reference, the dependency is >= 1.0.1-beta-df61s0df. The next build gets built but only one project gets updated, but the updated project now references the other project using the current commit id, but the current commit id just so happens to be sorted lower than previous version. The nuget update manager in VS thinks the older nuget package is the newest, when in fact there is one higher but has a commit id that is making it sort wrong.

Is there a way to fix this kind of issue with monorepos, or a feature can be added to enable using something like build id that is incremented each pipeline run and the commit id is set as metadata.

[AArnott]

Ah, your situation is particularly advanced, but not altogether unique. Let's see if I understand you correctly.

The next build gets built but only one project gets updated

It sounds like you either have a cached build system going on, or you've set up path filters. Without either of these, everything should "just work" because the version for every project would go up together.

but the updated project now references the other project using the current commit id,

This is a problem, as you say. But at least from what I've seen, it isn't that NBGV is computing inconsistent versions. Rather, that project A references B, asks B for its version and B tells it its current version. Except that B isn't building and deploying that version, so the version B tells A is wrong, since the last version of B that was deployed is something else.

Let me know if I'm right so far, and feel free to fill in any details. I've had to solve a problem like this in the monorepo that builds much of Visual Studio. But our solutions may or may not be compatible.

[johnwc]

Yes, that is correct. When using path filters, I would expect that project B should be looking for the commit id that it was last updated in and use that in its version.

[johnwc]

@AArnott can you share how you solved the problem with the other monorepos?

[AArnott]

The problem space is very complex and your specific situation may very likely lead to a different solution from mine. Really quick though, our mono repo uses a distributed, project caching system so that only a subset of the repo builds in any given pipeline run. Any project that builds sees the latest/current version, but its dependencies may not have built. Querying msbuild for the version of those dependencies would typically give you the 'current' version, but if that dependency hasn't built, that current version doesn't exist and won't ever exist.
Instead, one of the build outputs of a project includes a projectversion.txt file, which is cached along with the binary outputs. When the cloud build replays a project from cache, this file is also reconstituted on the build machine. So when a referencing project that actually builds asks its skipped dependency for its own version, that dependency project notices its own projectversion.txt file in its output directory and reports that version instead of the current version. This allows the referencing project to express a nuget package dependency to the older version.

But your problem with non-linear versioning is just that: non-linear versioning. If you're building in a branch for which versioning is not linear (i.e. publicReleaseRefSpec doesn't match on the branch name) then there's no scheme for computing versions that can make it linear, because in fact git branches and merges don't guarantee that it is linear.

This doesn't tend to be a problem because non-release branches build packages that shouldn't be depended on by anyone. So I'm curious how this became a problem for you. Are you actually using package references instead of project references within your mono repo? I can imagine the temptation to do that, but it creates a rash of problems.

Any more help than this in your particular situation will merit a consulting fee: https://blog.nerdbank.net/for-hire/