* Avoid unnecessary async-await
Since this is basically a linear script, we don't *really* need all this
async fluff, despite Node.js having a predisposition for async calls.
For one, it does not make much sense to immediately await an async call.
There is a synchronous version of exec -- execSync -- for that.
Suggested-by: Amin Yahyaabadi <aminyahyaabadi74@gmail.com>
* Make logging more verbose
Provide more insight in what paths are tried and where we have found
Visual Studio. Use info level so that it's visible without Actions
debugging being enabled. That way the users get to see a bit more
of the decision making process.
Instead of checking "vswhere" in PATH and then in the default location
explicitly, just add the default locatio to PATH. That makes a single
attempt sufficient.
GitHub Actions tutorials suggest that you should not commit Node.js crap
onto your master branch, but it's not like this action has a lot of
dependencies, and not being able to test "ilammy/msvc-dev-cmd@master" is
so annoying... Therefore, do
npm install --only production
and commit the results.
On some self-hosted runners "vswhere" is not available in the PATH.
Add another check in the findWithVswhere() function. It checks the
default installation of vswhere as stated by Microsoft, just in case
it is there but just not in the PATH.
Furthermore, the check refers to non-existent method core.warn()
instead of core.warning(). Use the correct method for reporting.
Recently added Visual Studio location with "vswhere" seems to be very
slow when using "-find" with path patterns. As in, 5 minutes slow.
vswhere does not provide much insight into why this happens, but I guess
that's because filesystem operations (and search in particular) are not
very fast on Windows.
Improve the search performance by combining vswhere with probing. Use
vswhere to locate the installation root, and then probe around for the
batch script we need.
Also, don't use vswhere for Visual Studio 2015 as it does not seem to
work. Rely only on probing here.
And also, add some debug logs so that it's possible to track which path
has been used, if you're interested in it.
The Windows images provided by GitHub have a native program called
"vswhere", which can be used to find vcvarsall.bat.
* use vswhere to find vcvarsall
* don't require child_process twice
* use vswhere to find the 2015 bat file
* refactor findWithVswhere
* move finding vcbuildtools using vswhere upward
* print error of vswhere
"Visual C++" has its build tool batch files in a different place.
Let's look there as well if we have not found 2017 or 2019 stuff.
Thanks to ReactOS project for figuring this out.
Co-authored-by: Victor Perevertkin <victor.perevertkin@reactos.org>
I'll probably use self hosted runners in a project and the Community
version of Visual Studio will be installed on those. This enables the
script to check for Community and Professional editions in addition
to the Entreprise one offered by GitHub.
The modification generates a kinda search map ordered by version then
by edition. It generates the batch script that runs vcvarsall.bat
on the fly given that search map.
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.
"npm audit" started whining about moderate denial of service
vulnerability in a dependency of dependency of dependency
(eslint > espree > acorn). This is not really serious because
we use "eslint" only for development. However, red builds are not good
so bump the pinned version in package.lock. (Released versions are not
affected because they do not include eslint.)
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.
Again, this is a squashed commit with around three hours of attempts
to write something working. See comments in the file for more details.
I'm too lazy to document this stuff properly.
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.
Alexei Lozovsky
Ewout ter Hoeven
Serge Camille
Nicolas Jarnoux
dependabot[bot]
Amin Yahyaabadi
Oleh Prypin
Sean Kelly