Skip to content

[release/5.0] Print and store versions at end of every build #2157

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

omajid
Copy link
Member

@omajid omajid commented May 6, 2021

This makes it easier to visually confirm what was built:

Build Info:
  SDK Version: 5.0.202
  ASP.NET Core Version: 5.0.5
  Runtime Version: 5.0.5

And also stores these values in named version files for later use.

The build output on the console looks like this:

  Build Info:
    SDK Version: 5.0.202
    ASP.NET Core Version: 5.0.5
    Runtime Version: 5.0.5

Build succeeded.

/home/omajid/devel/dotnet/source-build/packages/restored/microsoft.dotnet.arcade.sdk/5.0.0-beta.20426.4/tools/ProjectLayout.props(8,3): warning MSB4011: "/home/omajid/devel/dotnet/source-build/packages/restored/microsoft.dotnet.arcade.sdk/5.0.0-beta.20426.4/tools/RepoLayout.props" cannot be imported again. It was already imported at "/home/omajid/devel/dotnet/source-build/packages/restored/microsoft.dotnet.arcade.sdk/5.0.0-beta.20426.4/tools/Build.proj (49,3)". This is most likely a build authoring error. This subsequent import will be ignored.
<Lots of warnings
/home/omajid/devel/dotnet/source-build/repos/Directory.Build.targets(639,5): warning MSB4181: The "ValidateUsageAgainstBaseline" task returned false but did not log an error. [/home/omajid/devel/dotnet/source-build/repos/known-good.proj]
    7 Warning(s)
    0 Error(s)

Time Elapsed 00:47:44.01

And the files look like this:

$ find artifacts/build-info/ -iname '*.txt' -exec echo {} \; -exec cat {} \;
artifacts/build-info/SdkVersion.txt
5.0.202
artifacts/build-info/RuntimeVersion.txt
5.0.5
artifacts/build-info/AspNetCoreVersion.txt
5.0.5

Fixes: #600

@ghost ghost added the area-build Improvements in source-build's own build process label May 6, 2021
@dseefeld dseefeld requested a review from crummel May 13, 2021 19:09
@omajid omajid force-pushed the 5.0-show-build-version-info branch 2 times, most recently from 33489da to da5096b Compare August 23, 2021 20:19
@omajid omajid changed the title Print and store versions at end of every build [release/5.0] Print and store versions at end of every build Aug 23, 2021
@omajid omajid requested a review from crummel August 23, 2021 20:42
@omajid omajid force-pushed the 5.0-show-build-version-info branch 3 times, most recently from ce573d4 to cacf32a Compare August 24, 2021 17:29
@omajid
Copy link
Member Author

omajid commented Aug 25, 2021

CI is finally green 🥳

Copy link
Contributor

@crummel crummel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question about dotnet-sdk.tar.gz vs dotnet-sdk-internal.tar.gz. Other than that this looks great, thanks a lot!

This makes it easier to visually confirm what was built:

    Build Info:
      SDK Version: 5.0.202
      ASP.NET Core Version: 5.0.5
      Runtime Version: 5.0.5

And also stores these values in named version files for later use.

Fixes: dotnet#600
@omajid omajid force-pushed the 5.0-show-build-version-info branch from cacf32a to 45cd8d5 Compare August 25, 2021 20:27
Copy link
Member

@MichaelSimons MichaelSimons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this @omajid. I left a few comments.

AspNetCoreVersion = ExecuteDotNetCommand(SdkRootDirectory,
pathToDotNet,
new List<string> { "--list-runtimes" })
.Where(line => line.Contains("Microsoft.AspNetCore.App"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be simplified by utilizing a different First overload and the ElementAt linq method.

.First(line => line.Contains("Microsoft.AspNetCore.App")).Split(" ").ElementAt(1)

Copy link
Member Author

@omajid omajid Aug 27, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that suggestion. When you say "simplified", is that in terms of performance? If so, do you have any suggestions on resources (book, etc) I should take a look at to improve my understanding of performance impact of LINQ queries? Thanks in advance!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't expect any performance difference with the suggestion I made. I don't have any suggestions on resources. I have a personal perf harness I use to measure differences for scenarios like this.

.First()
.Split(" ")
.First();
AspNetCoreVersion = ExecuteDotNetCommand(SdkRootDirectory,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider storing the result of --list-runtimes instead of invoking it multiple times.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fixed!


<MakeDir Directories="$(ExtractedPath)" />

<Exec Command="tar xf @(FinalSdkTarball) -C $(ExtractedPath)" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 6.0 we've been trying to reduce the disk footprint of the tarball builds. It feels like the smoke-tests should reuse this location in CI. An alternative option is to grab the .versions files out of the tarball. Could these be utilized as is with a possible rename to satisfy the requirements? If not does it make sense to just grab the versions number out of them?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great idea! It should be possible to re-use the directory for smoke-tests. I am testing it now out now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for the idea. I have implemented it. Only caveat that I can think of is that now the tests will always assume that the already-extracted-sdk is pristine; if any test modifies it, the modification will persist to future test runs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, but on the other hand, I don't think this is something our tests should be doing either.

omajid and others added 2 commits August 26, 2021 19:12
This was suggested by Michael Simons in code review.

- Simplify the LINQ expression.

- Invoke `dotnet --list-runtimes` only once and keep the results.
@omajid omajid force-pushed the 5.0-show-build-version-info branch from c0783e6 to 5d64a7b Compare August 27, 2021 20:39
Modify smoke-test.sh to use the same extracted cli directory as the one
we use to parse the SDK/Runtime/ASP version.

The smoke-test.sh script offers to interactively delete
$SCRIPT_ROOT/smoke-testing if it exists. That interactive prompt breaks
CI. So we can't use the smoke-testing dir. Instead, point smoke-test.sh
to a different directory (outside of $SCRIPT_ROOT/smoke-testing) so it
can reuse that.
@omajid omajid force-pushed the 5.0-show-build-version-info branch from 5d64a7b to aa23c54 Compare August 27, 2021 23:50
Copy link
Member

@MichaelSimons MichaelSimons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR Omair!

@MichaelSimons MichaelSimons merged commit a298572 into dotnet:release/5.0 Sep 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-build Improvements in source-build's own build process
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants