It's smart to keep the NodeJS version pinned so we can run all build jobs
consistently.
Otherwise, we might run into some versions mismatch like below:
```
npm ERR! While resolving: @typescript-eslint/parser@2.30.0
npm ERR! Found: eslint@7.4.0
npm ERR! node_modules/eslint
npm ERR! dev eslint@"^7.4.0" from the root project
npm ERR! peer eslint@"^5.0.0 || ^6.0.0 || ^7.0.0" from @typescript-eslint/eslint-plugin@4.11.1
npm ERR! node_modules/@typescript-eslint/eslint-plugin
npm ERR! @typescript-eslint/eslint-plugin@">=2.25.0" from eslint-plugin-github@4.1.1
npm ERR! node_modules/eslint-plugin-github
npm ERR! dev eslint-plugin-github@"^4.1.1" from the root project
npm ERR! 7 more (@typescript-eslint/experimental-utils, ...)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer eslint@"^5.0.0 || ^6.0.0" from @typescript-eslint/parser@2.30.0
npm ERR! node_modules/@typescript-eslint/parser
npm ERR! dev @typescript-eslint/parser@"^2.30.0" from the root project
npm ERR! @typescript-eslint/parser@">=2.25.0" from eslint-plugin-github@4.1.1
npm ERR! node_modules/eslint-plugin-github
npm ERR! dev eslint-plugin-github@"^4.1.1" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: eslint@6.8.0
npm ERR! node_modules/eslint
npm ERR! peer eslint@"^5.0.0 || ^6.0.0" from @typescript-eslint/parser@2.30.0
npm ERR! node_modules/@typescript-eslint/parser
npm ERR! dev @typescript-eslint/parser@"^2.30.0" from the root project
npm ERR! @typescript-eslint/parser@">=2.25.0" from eslint-plugin-github@4.1.1
npm ERR! node_modules/eslint-plugin-github
npm ERR! dev eslint-plugin-github@"^4.1.1" from the root project
```
There is a few use cases where we want to download a few different artifacts but
not all of them. This commit implements this support, without breaking backward
compatibility. A build test case was also added to the pipeline.
The original text implies by supplying no inputs all files are placed in the root directory without added directories by focusing only on the `path` input. In practice, supplying no inputs results in the backwards compatible `v1` behavior of creating an extra parameter. This may be obvious in some scenarios and stated somewhat later in the document, but is less obvious when the "name" matches a filename for a single file artifact.
From February 2021, in order to provide feedback on pull requests, Code Scanning workflows must be configured with both `push` and `pull_request` triggers. This is because Code Scanning compares the results from a pull request against the results for the base branch to tell you only what has changed between the two.
Early in the beta period we supported displaying results on pull requests for workflows with only `push` triggers, but have discontinued support as this proved to be less robust.
See https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#scanning-pull-requests for more information on how best to configure your Code Scanning workflows.
