Also commit changes to files in `generated` (Automatically?)

[Dionysusnu]

Current convention has mostly been not to stage/commit changes to files in generated when submitting PRs. In the most frequent case of adding a single item to customDefinitions.d.ts, this often leads to single small commits (example) titled "Update generated files" which are just copying over the custom definition to the generated file. For the git blame, it would be better if these were part of the PR itself.

I can think of two solutions:

1. Just have authors do it themselves
   1. If we enforce this as a requirement, it becomes tedious to use the web editor for one line changes; You could make the change, but would then have to pull the branch locally to build the generated output.
   2. If we don't enforce it as a requirement, commits can become inconsistent, with some updating generated while others still create an update commit after the PR.
   3. There is a small risk of malicious changes in the generated going unspotted during PR review. I don't think this would be a major risk, as the automatic generation on master would run directly after and fix the malicious files? But it's still worth pointing out.
2. Have a CI job run and commit the generated output to the PR branch automatically
   1. Seems like a great solution, but is it viable?
   2. This solves the risk in 1.iii, as long as the job runs consistently and is checked for failure.
   3. How do we handle the case of people unchecking the Allow edits by maintainers option? I believe this would mean the CI job can't commit either. This basically falls back to the consideration in 1.i and 1.ii, although 1.iii shouldn't be a problem as long as the CI job still does a diff check when it fails the commit permissions.

[Dionysusnu]

For option 2, care needs to be taken to prevent vulnerabilities in the action, since it needs write permission but also runs user code*. See also https://securitylab.github.com/research/github-actions-preventing-pwn-requests/. It looks like the ReceivePR.yml CommentPR.yml example is good as a rough guide.

*Alternatively, we could have option 2 only apply to .d.ts changes (like customDefinitions.d.ts), which would get around the risks of running arbitrary PR code. I don't think this will be necessary though if we set up the two-workflow example correctly.