Can binlogs have customized names?

[wtgodbe]

In a discussion on this PR, it came up that Arcade prefers repos to always use the default build.binlog name as a piece of shared infra. There was also discussion of a loss of ability to do analysis on repo's binlogs when we customize their names. Currently AspNetCore gives its binlogs distinct names, the reasoning being that it's easier to identify a downloaded binlog that way, and that several of our CI legs are broken into multiple steps, each of which produces a binlog (e.g. the Windows build does x64, x86, then installers, sequentially). I wanted to open a discussion to see if we could reach a conclusion on what's right here.

CC @markwilkie @tmat @dougbu

[dagood]

Some binlog names are customized in dotnet/core-setup and dotnet/runtime too, since some jobs run multiple Docker containers with separate build.sh calls.

(I think it would be good to collapse that, but haven't had a concrete reason to drive that, and I don't think this reaches that bar either. (One way to resolve it in runtime/core-setup is to use fpm everywhere, rather than distro-specific tooling, dotnet/runtime#3383 (comment).))

[tmat]

There are multiple aspects of this question.

Building in multiple phases within a single pipeline job

Looking at https://github.com/dotnet/aspnetcore/blob/master/.azure/pipelines/ci.yml#L126 for reference.

This pipeline job has a sequence of calls to build.cmd script listed in YAML each with different switches. Since yaml is not executable locally any logic that's in it is not reproducible on dev machine without extracting it manually from yaml first. Arcade thus strongly prefers to have a single build entry point script. This is reflected in the common build.ps1|sh being designed to be called only once as it is the entry point script.

The common\build.ps1|sh script is provided for convenience for repos that just need a single MSBuild call to restore, build, package and test everything. Most of the actual logic is in common\tools.ps1|sh. The common\build.ps1|sh script is just a thin wrapper calling into functions defined in common\tools.ps1|sh .

This separation is intentional and it allows repos to author their own build.ps1|sh script that can do multiple invocations to MSBuild and any number of other operations. This approach is used by dotnet/roslyn, dotnet/runtime and other repos.

My recommendation would be to move all the build.cmd calls from YAML to a build.ps1 file and use the above approach.

binlog names, multiple binlogs

I believe it is useful to have common naming convention for the main binlog produced by the build. That doesn't mean there might not be other binlogs. If repo uses a custom eng\build.ps1|sh script it can specify /bl parameter to each MSBuild call with any file name.

In fact, we already do that in Roslyn:

My recommendation would be to name the main build log Build.binlog to make it easy for people working with multiple repos, the community and tools to easily find it.
I believe this consistency is more important than the convenience of "easier to identify a downloaded binlog that way", in case you're downloading multiple binlogs from different CI legs. I don't think it's that hard to give a downloaded file a name. Naming the log after the leg name also doesn't make it unique for other scenarios like downloading logs from multiple builds or from multiple repos. Should we also include the repo name and the build number in the name of the binlog?

separating restore and build binlogs

Turns out msbuild isn't able to handle huge binlogs. It'd also be more convenient to have logging for restore phase separate from logging for build phase. These are logically separate phases and it is usually clear whether an issue is in restore or in build phase, and thus what binlog one would want to look at.

Currently common\build.ps1|sh calls MSBuild once with /p:Restore=true /p:Build=true /bl:Build.binlog args. We could easily make two calls with /p:Restore=true /bl:Restore.binlog and /p:Build=true /bl:Build.binlog, respectively. We might want to measure an impact on build times before we do that. But at least the repositories that run OOM, could do this in their custom eng\build.ps1|sh script already as a workaround to the msbuild issue.

[dougbu]

We use tools.ps1|sh and have no plans to either further complicate our build.ps1|sh scripts (they already handle a lot) or start using eng/common/build.ps1|sh. We have build.cmd scripts in lower folders that mostly manage the required steps in the cases where multiple steps are needed e.g. when we need to build both x64 and x86 architectures.

We might figure out why avoiding msbuild except where absolutely necessary hasn't worked so far. And, we may try @rainersigwald's suggestion to use the 64bit msbuild. Neither will change our need to override the binary log names.

BTW when we build both architectures on Windows, one (x64) runs first but isn't really "primary".

[dougbu]

Just noticed even Arcade's pipeline has multiple build steps in some of its jobs. But, its approach makes it clear we don't need anything more. -ci … /bl:{some path} works fine. (I was wondering this about the previous "workaround" in dotnet/aspnetcore.)

[markwilkie]

@wtgodbe - I presume you're also ok w/ closing this issue given both the discussion and the approach @dougbu is going with?