There's a required PR validation check on master that requires some checks to run that don't actually trigger on doc changes. This means doc PRs are never green and can't be merged by ordinary users. Without any guidance (clear pathway to get unblocked) this is a terrible experience and discourages doc updates.
Ideas:
@markwilkie
discourages doc updates.
This is definitely true @dagood. The admins for Arcade are fine w/ mashing the merge button. Do you have any thoughts on making it more clear the process?
As you say, we could alternatively turn back on all the PR build validation pieces for docs.... thoughts?
I think we should turn them back on. This is the only repo where we have this workflow, and I don't think it saves us much when it comes to machine savings. The merge still triggers a CI build and official build that are both giant no-ops too, so the burden on the PR author seems unwarranted.
I'm fine w/ that too. @riarenas, you mind doing that?
A PR template that mentions this quirk and includes a list of people to ping (or a github team) would be enough.
Enabling CI to get rid of the need for special handling would of course be ideal. You could consider making the CI short-circuit if it detects no changes on the CI side like dotnet/runtime. https://github.com/dotnet/runtime/blob/master/eng/pipelines/common/checkout-job.yml
I think we can get away with just enabling the builds back on. I like the idea of the CI short-circuit if we see that this is putting a lot of strain on the build machines.
Fixed by https://github.com/dotnet/arcade/pull/5203. Thanks!
Most helpful comment
I think we should turn them back on. This is the only repo where we have this workflow, and I don't think it saves us much when it comes to machine savings. The merge still triggers a CI build and official build that are both giant no-ops too, so the burden on the PR author seems unwarranted.