Design method to communicate MS build info to SB partners

[mmitche]

In order to collaborate with our distro partners and enable their daily CI workflows, we need ways to communicate information about Microsoft's builds. For released builds, we have a release.json that is added to the release info on GitHub, which distro partners can use to determine how to launch their builds. This doesn't work today for a rolling CI though.

We need a way to resolve this. Requirements:

• Should be possible to draw a line from a sha of dotnet, to the build settings if there was a successful build
• Multiple builds of a sha should be supported.

[mmitche]

Some possibilities:

• Emit a build settings file as part of published assets. Publish to something like ci.dot.net/public/<sha>/build.json
  • Pro: Fits within existing infra
  • Pro: Can link to latest
  • Con: How to deal with multiple builds (can't overwrite file)
• Emit info into the git notes stream
  • Pro: Easy to add multiple builds per sha
  • Pro: Discoverable locally on a dev box
  • Con: Use of git notes is relatively new to us
  • Con: Do distro partners have the git repo in their infra? Would they need it?

[mmitche]

/cc @dotnet/source-build @dotnet/distro-maintainers

[omajid]

Con: Do distro partners have the git repo in their infra? Would they need it?

For Red Hat's internal CI builds, we clone full git repos, and we have full access to git tooling and the full contents of the git repo. I think we will just need to update our clone/fetch commands to make sure notes are pulled down too.

(In contrast, for our production builds for packaging for various Linux distros, we currently use release tarballs and not git repos directly).

[MichaelSimons]

@mmitche is this something on your radar?

[mmitche]

Lower priority now, given where we are in the product cycle.