When PR validation spans a UTC day, the Installer build may fail due to a package version mismatch

[dagood]

Seen in #1059 (comment)

That looks like a build issue. @ViktorHofer @dagood I thought the live-live build was working now? That looks like it's referencing packages from yesterday?

#839 documents that you need to do a fresh build whenever you cross a day boundary. Looks like it applies to CI as well.

I believe this is a combination of:

• OfficialBuildId isn't passed in, which makes the version number non-repeatable.
• We use date-based versions in our non-official builds in the first place. I dislike this, and filed Can we use "dev" prerelease tag for local builds, rather than "dev.12345.1"? #246 a while back for it.

It looks like the original error was also caused by UTC day tickover. Here's the timestamp on the first line of a failing Installer build step in attempt 1:

2019-12-20T00:03:04.6739571Z

Core-Setup stopped having this problem once it moved off BuildTools onto Arcade. Now we've got it again because of global dotnet/runtime settings.

Right now, any build where Libraries => Installer spans a UTC day should fail this way.

[dagood]

@dotnet/runtime-infrastructure

[safern]

@dagood what is the recommended fix here? Should these dependencies flow differently rather than via nuget packages?

[dagood]

I would recommend stopping using date-based versions for non-official builds. IIRC there was some DLL versioning issue in CoreCLR that was tied to this, but I don't see it written down anywhere.

Bypassing packages in asset flow would also work, but could require more work.

[safern]

Bypassing packages in asset flow would also work, but could require more work.

I agree, but wouldn't that be the best long term solution?

[dagood]

Yep. However I do think that we should do both, either way, for the reasons in #246.

[safern]

We just hit this in: https://dev.azure.com/dnceng/public/_build/results?buildId=483315&view=logs&jobId=6fbc756c-b955-5d25-715b-83193faff4f9

Might be worth bumping the priority of this issue.

[dagood]

Fired off #1835 to remove the date number and see what breaks. This isn't currently on my backlog though.

[jkoritzinsky]

Another instance in https://dev.azure.com/dnceng/public/_build/results?buildId=488460&view=logs&jobId=0ae671a0-c5c0-596d-9a9c-5c8cba56c6c8&j=0ae671a0-c5c0-596d-9a9c-5c8cba56c6c8&t=d6ec3c78-037b-5ec7-c41b-a4cbf9e8f94f

[josalem]

Another instance (I think): https://dev.azure.com/dnceng/public/_build/results?buildId=493235&view=logs&j=2791e618-2801-5f48-69d0-0f90735f98ed&t=075af249-21c5-5cbe-f092-1b65559d652d&l=676