Instead of the v1 tag, that is. This makes it possible to push changes
to release/v1 branch and get CI test them without actually moving the
release tag which effectively publishes the updates to users.
* Update glob-parent to resolve CVE-2020-28469
* Run audit tasks on Ubuntu runners (they are cheaper)
* Audit only production dependencies
That is, something that can actually affect users of this action.
I don't really want to be bothered with yet another "prototype pollution"
or "denial of service" in transitive dependencies of eslint.
* Audit dev-dependencies for critical vulnerabilities
That said, still audit development dependencies for critical
vulnerabilities if they come along. Hopefully, this should be rare.
* Workaround for repeated invocations
As noted in the comment, repeated invocations of this action might have
caused environment variables to overflow. This cute hack avoid this,
allowing to reconfigure environment.
* Note caveats in README
While this approach mostly works, I still have reservations so let's
leave some cautionary notes.
* Test repeated reconfiguration on CI
Well, let's build our "Hello, world!" four times, for four different
architectures, because why not.
By a public request, let's support aliases for architecture parameters.
Treat "arch: Win32" as "x86" and "Win64" as "x64".
Test this on CI just in case x86 breaks or something.
Set the threshold to "moderate" and above. Currently msvc-dev-cmd has
an issue in transitive dev-dependency "minimist" [1] via somewhat long
chain of dependencies:
- eslint > file-entry-cache > flat-cache > write > mkdirp > minimist
- eslint > mkdirp > minimist
In order for this to be resolved all these packages need to do something
about their pinned versions. I don't want to sit there with a red build
because of some possible low-severity prototype pollution in dev
dependency. Anything higher -- okay, I'll look at at, and apply a fix
if necessary. (Maybe we should not audit dev dependencies at all...)
This particular vulnerability can be exploited by an attacker who can
submit a pull request and do "something bad"™ to Actions runners
executing jobs for this repository. However, since it's a dev
dependency, nothing will happen to our users. So we can safely ignore
this advisory.
[1]: https://npmjs.com/advisories/1179
I'd like to be notified about weird vulnerabilities in JavaScript
libraries for the release branch as well. It's double important
since the release branch ships particular pinned version of *all*
dependencies.
It's not like we need any new features, but let's bump the versions
because we are in JavaScript land.
Also, run "npm audit" regularly, just in case a serious vulnerability
is discovered.
Well, it seems the environment is changing so we'd better run the tests
reguarly to see whether something breaks in a timely manner.
GitHub Actions also don't offer other Windows environments now, only
windows-latest is available. Reduce test matrix to only that.
Try compiling some C code, If it works then we're probably fine.
I don't even try to verify cross-compilation because I don't need it.
It should work, but that's not my problem right now.
Now that I know how to write some simple action, let's make a stub
more complete. For example, I already know what inputs I would like
to handle for this action.
Maj Soklič
Oleksii Lozovskyi
Mozi
Ewout ter Hoeven