Repository navigation
Stamp the commit sha into the published image - #1400
Merged
Merged
Conversation
A deployed pod reported "Running build 1.0.0" -- a version that cannot tell two deployments apart, which is the only thing a build identity is for. The publish never passed SourceRevisionId, so the SDK had nothing to append. Both Dockerfiles now pass it, from a build arg when the pipeline knows the sha and from the copied .git otherwise, falling back to "unknown" rather than to a version that looks meaningful and is not. BuildIdentity also stops reading Assembly.GetEntryAssembly(). The entry assembly is whatever launched the process: under dotnet test that is the VSTest host, which reported 17.12.0 -- a Microsoft tooling version presented as ours. It now reads the assembly it is defined in, which every host ships and which is built from this repository.
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.
Summary
A deployed pod reported:
1.0.0cannot distinguish two deployments, which is the only job a build identity has. The publish never passedSourceRevisionId, so the SDK had nothing to append toAssemblyInformationalVersion.SOURCE_REVISION_IDbuild arg when the pipeline knows the sha, from the copied.gitotherwise, andunknownas the last resort rather than a version that looks meaningful and is not.BuildIdentityno longer readsAssembly.GetEntryAssembly(). That is whatever launched the process; underdotnet testit is the VSTest host, which reported17.12.0— Microsoft's tooling version presented as ours. It now reads the assembly it is defined in.Verified the attribute actually lands, rather than assuming it:
Test plan
BuildIdentityTests—It_carries_the_source_revisionreded on the real defect (Build identity is '17.12.0') before the entry-assembly fix-p:SourceRevisionIdstamps1.0.0+<sha>into the published assembly