API report checks - OPTIONS

[vidartf]

This PR outlines a few options for how to start enforcing / using the API extractor reports:

1. Add a check to the Travis build to see if the files are up to date. If not, fail and ask the user to run the "yarn api" command and commit the results.
2. Add a similar check to 1., but using a GH action. Mostly there for completeness.
3. Run the comparison, but don't fail the check if there are differences. Instead report the differences as a warning. The warning mechanism is incomplete at the moment, but alternatives include:
   1. Use a bot to post the diff as a comment (that ideally gets updated).
   2. For each change, figure out the file (and ideally line) of that change. Use Github warnings to highlight those on the diff (see next point). This would depend on https://github.com/microsoft/rushstack/issues/895 .
   3. Use a github warning on some more central file. The current code puts it on the root package.json, and doesn't currently include the diff. Not the cleanest, but it is still better than nothing.

[vidartf]

It seems as if the GH actions don't run when initiated from forks, so here is one where they run (no travis though): https://github.com/vidartf/lumino/pull/1

[vidartf]

Here is the current warning message: https://github.com/vidartf/lumino/pull/1/files#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R1

[dhirschfeld]

It seems as if the GH actions don't run when initiated from forks

Maybe that's being fixed?' https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks

[vidartf]

It seems as if the GH actions don't run when initiated from forks

Maybe that's being fixed?' https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks

I meant that it doesn't run when the workflow files doesn't currently exist on the target repo. That PR would not fix that (I think the current behavior is probably a good one), but rather a closely related issue (if someone make a PR with changes to existing files, use the existing files to check that PR). It makes sense as by modifying the actions you might be able to perform certain actions permissioned as the action executor (i.e. by access to secrets, you might be able to run certain commands on remote systems), or e.g. mine bitcoin using the resources of other projects.

[fcollonval]

Closing as this is now part of the CI

The PR job will fail if the API changes. It is up to the PR author to either commit the API changes or modify the PR to avoid the changes.