* Upgrade "ansi-regex" 5.0.0 => 5.0.1
And various other stuff because npm can't just upgrade one thing in the
lockfile, it need to upgrade everything it can. Move along, nothing
interesting to see here.
* Upgrade "eslint" 6 => 7
And also unpin the minor version. This resolves a bunch of "critical"
audit advisories from transitive dependencies.
* 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.
Also updating and adding whatever the new version of npm wants to be
updated and added in its package files. This should not affect the
behavior of the action.
Printing them line by line will generate a bunch of error messages on
the summary page of GitHub Actions workflow. I think it's a bit
annoying.
Note that this change will also affect the format of the final output
error message, but no information will be lost.
* 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.
* Use newer actions/checkout@v2 in examples
That's the current version. Even our own build scripts use it.
* Correct actions syntax
By the way, it's been ages since steps get their own section...
* Provide an example with matrix
Finally, have some example to showcase input usage.
* Move inputs after examples
Since they are more useful, put copy-pastable examples first. Then you
can look at all available inputs, now that you know how to use them.
Just another day in JavaScriptLand: some "HIGH PRIORITY" vulnerability
has been fixed (CVE-2021-23337). Update our package-lock.json version
too because npm wants that.
(cherry picked from commit f5e8657374)
I'm doing this to shut GitHub Actions CI. It might be a good idea to
make a minor release with this as well. We'll see. But CI is going to
use the "release/v1" branch code and "npm audit" will complain.
Just another day in JavaScriptLand: some "HIGH PRIORITY" vulnerability
has been fixed (CVE-2021-23337). Update our package-lock.json version
too because npm wants that.
Instead of using a hardcoded list of variables to export, use a more
smart approach: first inspect the original environment, then look what
variables have changed as a result of "vcvarsall.bat" invocation, and
export all those new values.
Also, log the variables we export to be more debugging-friendly.
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.
If the parameters passed to the script are incorrect -- for example,
architecture is set to something the script does not understand --
then the script will print an error message *and* exit successfully
without doing anything useful.
Detect the error messages, forward them to the user, and fail the
action. Hopefully, the information from the script will be enough
to pinpoint the source of the issue.
For example, if the action is run
with:
arch: Win32
then the output will be
Found with vswhere: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat
Error: [ERROR:vcvarsall.bat] Invalid argument found : Win32
Error: Could not setup Developer Command Prompt: invalid parameters
which is close enough.
* 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.
Alexei Lozovsky
Mathias LANG
Amin Yahyaabadi
Darrell Wright
Mozi
Frederik Seiffert
Ewout ter Hoeven
Serge Camille
Nicolas Jarnoux
dependabot[bot]
Oleh Prypin