[monobuild] Guard 'Get build revision number' against non-date build numbers (fix Foundation stage) - #6649
Draft
kythant wants to merge 2 commits into
Draft
Conversation
…numbers The Foundation stage of the Official mono-build (build 152839452) fails in every Build Foundation / Build MRT job at 'Get build revision number' with: Exception calling "Substring" with "2" argument(s): "StartIndex cannot be less than zero." WindowsAppSDK-SetupBuildEnvironment-Steps.yml extracts yyMM/dd/revision from BUILD_BUILDNUMBER using fixed end-offsets (length - 10 / -5 / -3), which assumes the standalone pipeline-name scheme $(date:yyMM).$(date:dd)$(rev:rrr) (>=10 chars). The mono-build passes a short semantic build number (Official "2.0.0", 5 chars), so length - 10 is negative and Substring throws, failing the whole Foundation stage (the later 'Not found SourceFolder ...\BuildOutput' errors are cascades of the aborted build). These builddate/buildrevision variables are set here and consumed nowhere else in the repo, and in the mono-build Foundation is versioned from $(WindowsAppSDKFormattedVersion), so the values are unused there (the Nightly mono-build already ran green producing throwaway values from its longer build number). Guard the fixed-offset extraction behind a length >= 10 check and fall back to zero date/revision otherwise. Preserves exact behavior for the date-based standalone build numbers.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
BuildAll.ps1 (the actual Foundation build script) has an identical copy of the BUILD_BUILDNUMBER Substring logic, and it is the REAL consumer of the value: the extracted yymm/dd/revision feed /p:WindowsAppSDKVersionBuild + /p:WindowsAppSDKVersionRevision, which stamp the Foundation binary/package version. (The builddate/buildrevision pipeline variables set in WindowsAppSDK-SetupBuildEnvironment-Steps.yml are a dead duplicate consumed nowhere.) The SetupBuildEnvironment step crashes first on the mono-build's short "2.0.0" build number, but once that is guarded the build would crash again here. Apply the same length >= 10 guard so the mono-build (Foundation versioned from $(WindowsAppSDKFormattedVersion)) doesn't throw.
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
Fix the Foundation stage crash in the WindowsAppSDK mono-build. The build-revision extraction throws
Substring ... StartIndex cannot be less than zeroon the mono-build's short semantic build number.Root cause
Two copies of the same logic slice
yyMM/dd/revisionout ofBUILD_BUILDNUMBERwith fixed end-offsets (length - 10 / -5 / -3), which assume the standalone pipeline-name scheme$(date:yyMM).$(date:dd)$(rev:rrr)(>= 10 chars):build/AzurePipelinesTemplates/WindowsAppSDK-SetupBuildEnvironment-Steps.yml(theGet build revision numberstep) -- setsbuilddate/buildrevisionpipeline variables. These are a dead duplicate (consumed nowhere in the repo).BuildAll.ps1-- the REAL consumer: the extracted values feed/p:WindowsAppSDKVersionBuild+/p:WindowsAppSDKVersionRevision, which stamp the Foundation binary/package version.The mono-build passes a short semantic build number (Official = "2.0.0", 5 chars), so
length - 10is negative andSubstringthrows. TheGet build revision numberstep crashes first (observed in Official mono-build 152839452, failing everyBuild Foundation/Build MRTjob; theNot found SourceFolder ...\BuildOutputerrors are cascades) -- andBuildAll.ps1would crash the same way right after. The Nightly did not hit this because its build number (2.0.0-dev.experimentalNNN) is > 10 chars.Fix
Guard both copies behind a
length >= 10check; otherwise fall back to zero date/revision (and log it). Exact behavior is preserved for the date-based standalone build numbers; only the previously-crashing short-number (mono-build) path changes.Why zeros are safe
In the mono-build Foundation is versioned from
$(WindowsAppSDKFormattedVersion), and the Nightly already ran green producing throwaway values from its longer build number -- so these date/revision values do not drive the shipped version. The YAML step'sbuilddate/buildrevisionvariables are unused entirely.Validation
ifblock;SetupBuildEnvironment-Steps.ymlstays pure CRLF,BuildAll.ps1stays pure LF.release/dev/monobuild(the branch the mono-build checks Foundation out at).