no need for the BUILD_FILES env var

[peterbe]

Here's the problem, it seems the yarn install stuff isn't getting cached at all.

Cool! It totally works.

Now, taking care of yarn and node_modules takes ~7s on a warm cache. And a warm cache is extremely likely on this repo because 9 out of 10 PRs are expected to be edits to the files/**/index.html files.

Unlike the "default suggestion for Node Yarn" I opted for the same solution we're doing for the poetry install in Yari.
And this is actually the recommended way for "Node - Lerna".
The net effect is that we cache the whole node_modules directory. And it's keyed by OS and by yarn.lock so it's very unlikely that a cache hit is stale.

[peterbe]

This change was the original thing I wanted to change. Now the build/cli.js is a caporal CLI app, its default argument is (0-N) the file paths to the index.html files to build. This used to not be possible before.
Depending on BUILD_FILES never felt great because it's a string that you need to manually split up. By relying on UNIX principles (aka. bash and caporal) you're instead letting them take care of that.

[peterbe]

@escattone This PR became a double-concern thing. I first wanted to change how we invoke the builder based on the git diff (from get-diff-action). Then I noticed that the Yarn caching always failed!
First, when I tried to fix the yarn caching problem I tried a couple of different things and debugging. But the best solution I could ever come up with was to basically cache the HTTP traffic that yarn install would eventually have to depend on. Well, what if we can not do the yarn install at all, if we don't really have to. It's the same thing I did in https://github.com/mdn/yari/pull/1767/files
It used to be that the best-case was that yarn install would not need to do any HTTP downloads from npmjs.com but would still need to the disk I/O of unpacking moving tarballs from its internal cache and exploring them into $CWD/node_modules/. So why not bypass the whole enchilada?

[escattone]

@peterbe I like it.

[escattone]

@peterbe I don't know why the core-yari-content team was added as a reviewer. The one file this PR changes isn't "code-owned" by that team. Strange.

[peterbe]

@peterbe I don't know why the core-yari-content team was added as a reviewer. The one file this PR changes isn't "code-owned" by that team. Strange.

Probably because, at least at some point, I did make an edit to one of the files/en-us/**/index.html files so the get-diff-action would trigger at all.