Automate some release tasks/sanity checks for Servicing

@wtgodbe commented on Wed Apr 03 2019

We should attempt to automate the following things (or at least, automate validation for the following things):

• Branding updates
• Packaging changes for CoreFx PRs that touch libraries with OOB packages
• Release tags

Related: https://github.com/dotnet/corefx/issues/36570

CC @mmitche

---

@wtgodbe commented on Wed Apr 03 2019

Branding updates look like the following in 2.x:

CoreFx: https://github.com/dotnet/corefx/pull/34433/files CoreClr: https://github.com/dotnet/coreclr/pull/23067/files Core-Setup: https://github.com/dotnet/core-setup/pull/5354/files

---

@wtgodbe commented on Wed Apr 03 2019

For Packaging, we’d need a mechanism to ensure the following things:

• All servicing-approved PRs are merged
• The built SHA comes later in the history than all of the merged servicing-approved PRs
• Every servicing-approved PR has had its packaging reviewed by me, @safern, @joperezr, or @ericstj

If we can figure out a way to automate ensuring that packaging was done correctly (rather than having a human reviewing it), that’d be ideal, but that might be a stretch.

---

@wtgodbe commented on Wed Apr 03 2019

For Release tags, we’d need a script that cracked open the shipped Microsoft.NetCore.App package, read the SHAs from Microsft.NetCore.App.versions.txt, grabbed the CoreClr SHA from CoreFx’s dependencies.props (at the time of the CoreFx SHA), and grabbed the SHAs from the latest auto-update PR in CoreFx & Core-Setup (might be tricky).

---

@mmitche commented on Wed Apr 03 2019

/cc @vivmishra @leecow

Thanks @wtgodbe. I think the “did my fix end up in the built sha” section of this should be applicable across the entire stack, with some tweaks here and there. The branding/packaging verification gets a little harder and more repo specific. aspnet/extensions has the same issue that corefx does. Can you work with @dougbu to come up with something applicable there too? I’d also add that we should be able to verify fixes make it up the servicing chain too.

Ideally, I see this as a tool that:

• If it passes, we got everything right
• If it fails, it may be that something is wrong. It requires a second look and the tool will provide enough output to diagnose
• ‘Failure’ is pretty liberally applied and takes into account things people may do wrong when tagging issues, making PRs, etc. For instance, it would be better to fail (or warn) when a repo has no approved for the coming release than assume that there are simply no fixes. While the latter is common, it makes it less likely that a change in tagging behavior or such will cause us to miss things.

---

@mmitche commented on Wed Apr 03 2019

I’m gonna move this to the arcade repo because I think it needs to be a cross repo tool…Okay @wtgodbe?

[mmitche]

I think this is 2.x servicing, not 3.x. I think it’s in the wrong epic.

[jcagme]

Gits tags can now be created with https://github.com/dotnet/arcade/issues/4252, branding will now be tracked by #4371 so closing this. Feel free to reopen if keeping this around makes more sense