Wire up nuspec-based pack to deterministic mode

[omajid]

Bug

Fixes:

Description

When building nuspec-based packages, the deterministic-mode configuration is not flowed correctly to the PackageBuilder class (which is initialized using this PackArgs object). Seems like this was missed from the initial deterministic support in #2989.

This commit is a no-op until deterministic mode is enabled and NuGet/Home#8601 is fixed.

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.

[omajid]

I don't have permissions to re-open :(

[akoeplinger]

I do :)

[akoeplinger]

I guess if you want to get this reviewed you'd need to move it from Draft to Ready for review

[omajid]

Thanks for re-opening.

I plan to add some tests, and fill out the PR forms before making it ready for review.

[omajid]

This is still on my plate, just a bit lower priority. I plan to work on this some time in the next few weeks.

[zivkan]

This commit is a no-op until deterministic mode is enabled and NuGet/Home#8601 is fixed.

What is the benefit of this PR if deterministic mode is not enabled?

Given that the last time deterministic mode was tried back in 2019, that it caused a whole bunch of people serious issues and the feature had to be removed, my concern is that looking at this PR's diff is not enough to determine whether this PR is safe to accept. Additional validation would be needed to ensure that pack of both projects and nuspec files do not result in packages with fixed timestamps. But since this does not change behavior from a customer point of view, time spent validating "nothing has changed" is less valuable than fixing bugs, adding features, or even working on docs.

My suggestion is to avoid working on anything related to deterministic pack's implementation until it's determined that deterministic pack is safe to re-enable. If someone dislikes PackArgs having a Deterministic property that is unused, there is less risk in deleting the property than there is in wiring up the property to have a value and accidentally enabling it before the root cause behind 2019's rollback is resolved. I don't want to make it look like the NuGet team didn't learn from 2019

[omajid]

What is the benefit of this PR if deterministic mode is not enabled?

Nothing.

I am working on re-enabling it, and this was an isolated bug-fix from everything else in that change.

My suggestion is to avoid working on anything related to deterministic pack's implementation until it's determined that deterministic pack is safe to re-enable.

Okay.

[dotnet-policy-service]

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 30 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.