refactor: generate built-in plugin hashes at build time instead of committing them - #675
Merged
Merged
Conversation
…mmitting them PluginValidator's hash table was a committed file regenerated after the build that produced it, then committed as a new commit. That ordering could never be right: the table described the previous build's binaries, and committing it changed HEAD, which changed the binaries again. CI papered over it by auto-committing the churn on Development and by gating fork PRs on a diff that could not come out clean. Generate it during the build instead. PluginHashGenerator.targets hashes the plugin DLLs before PluginRegistry compiles and writes the table into obj/, so every build's table matches that build's own binaries by construction. The plugins are guaranteed to exist first via build-order-only ProjectReferences (ReferenceOutputAssembly=false) from PluginRegistry to each plugin project - making explicit a dependency PluginRegistry already had, since it hardcoded their hashes. Hashing now uses MSBuild's built-in GetFileHash rather than a separate console project, which also breaks the cycle that project would otherwise create: it referenced PluginRegistry, which now needs the table before it compiles. Removed as a result: - src/PluginHashGenerator.Tool (the console generator) - the committed PluginHashGenerator.Generated.cs - Nuke's GeneratePluginHashes target, including the PluginRegistry rebuild it needed and the version-stamping hazard that rebuild carried - the Generate / Verify / Commit steps in build_dotnet.yml, and that job's write permissions - the plugin-hash half of release.yml's generated-files PR This also makes commit-to-commit reproducibility unnecessary, so EnableSourceControlManagerQueries=false is reverted and SourceLink is restored. Verified on a clean Release build: all 21 table entries match the SHA256 of the DLLs shipped in bin/Release/plugins and pluginsx86, with the commit sha back in InformationalVersion. Debug and Release both generate 21 entries. Full suite passes: 1491 passed, 7 skipped, 0 failed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
refactor: generate built-in plugin hashes at build time instead of committing them
PluginValidator's hash table was a committed file regenerated after the build that produced it, then committed as a new commit. That ordering could never be right: the table described the previous build's binaries, and committing it changed HEAD, which changed the binaries again. CI papered over it by auto-committing the churn on Development and by gating fork PRs on a diff that could not come out clean.
Generate it during the build instead. PluginHashGenerator.targets hashes the plugin DLLs before PluginRegistry compiles and writes the table into obj/, so every build's table matches that build's own binaries by construction. The plugins are guaranteed to exist first via build-order-only ProjectReferences (ReferenceOutputAssembly=false) from PluginRegistry to each plugin project - making explicit a dependency PluginRegistry already had, since it hardcoded their hashes.
Hashing now uses MSBuild's built-in GetFileHash rather than a separate console project, which also breaks the cycle that project would otherwise create: it referenced PluginRegistry, which now needs the table before it compiles.
Removed as a result:
This also makes commit-to-commit reproducibility unnecessary, so EnableSourceControlManagerQueries=false is reverted and SourceLink is restored.
Verified on a clean Release build: all 21 table entries match the SHA256 of the DLLs shipped in bin/Release/plugins and pluginsx86, with the commit sha back in InformationalVersion. Debug and Release both generate 21 entries. Full suite passes: 1491 passed, 7 skipped, 0 failed.