There seems to be no good reason for testing on Node.js other than
the current LTS. Moreover, npm@6 has a wontfix issue when upgrading
to 8.4 on Windows, which requires a complex workaround: https://github.com/npm/cli/issues/4341#issuecomment-1040608101.
So avoid it by simply not supporting it.
Per https://github.com/actions/virtual-environments/issues/4856,
`windows-latest` will default to `windows-2022` soon (not later than
March, 6). Since it seems like we still run on `windows-2019`, force the
migration by specifying `windows-2022` explicitly.
Since https://github.com/actions/virtual-environments/pull/5050 is
merged, this should fix the failing Web tests on mismatched Chrome and
chromedriver versions.
TODO: Once `windows-latest` defaults to `windows-2022` (again, March, 6),
change back to `windows-latest`.
Upgrading to npm 8.4 on Windows is currently broken: https://github.com/npm/cli/issues/4341
This was avoided by disabling tests on Windows Node 14 in #6167.
Re-enable them by staying on npm 8.3 instead.
Move the `if` condition that tests for the Ruffle official repository
to the job-level, so all steps of that job are skipped, rather than
only the publish step itself. This should have a very little effect,
but I just randomly noticed it.
Publish nightly releases as part of the CI, so Ruffle can be easily
integrated into a website using a CDN (such as jsDelivr). It would
also be easier for websites to keep up-to-date, as NPM auto-updates
the `latest` tag to refer to the latest release.
A dedicated `package.json` is used for the published NPM package,
because `ruffle-selfhosted` depends on the private `ruffle-core`
package, which shouldn't be published.
Also, the `version` field must monotonically increase. So Webpack
auto-fills it to be `0.1.0-nightly.YYYY.MM.DD`. This format satisfies
a couple of needs:
* Newer nightly releases should take precedence over older ones.
* Stable releases (e.g. `1.0.0`) should take precedence over nightly
ones.
And enable the module that really uses WebAssembly extensions for the
releases by running the new "npm run build:dual-wasm" command, which
sets the ENABLE_WASM_EXTENSIONS=true environment variable.
`lerna` is a bit stale, and as such it currently has some outdated
dependencies which Dependabot warns on.
Fortunately, npm 7 supports monorepos natively, via "workspaces". So
simply replace `lerna` with this feature. The migration is pretty
neat and requires a very little invervention.
Because Node.js 14 comes with npm 6 by default, upgrade it manually
as shown in https://github.com/bahmutov/npm-install/issues/103#issuecomment-931226602.
The `error-report` label was not being added to error reports
submitted by panics in the web player, despite the `labels` query
parameter in the URL. Users do not have triage/write access to the
repo, which is required by GitHub to add a label to an issue.
Add an issue template for error reports with the `error-report`
label. This template is now added to the issue URL, which
automatically adds the tag regardless of access level.
ruffle.rs should be part of the Chrome WebGPU origin trial, so we
can enable wgpu feature to try it out.
It should gracefully fall back to WebGL when WebGPU is not
available.
As usual, also bump its helper crates (`js-sys`, `wasm-bindgen-futures`)
to the latest versions, except for `web-sys` which is locked by wgpu
to 0.3.50.
The previous approach of `paths-ignore` was flawed because currently
it doesn't interact well with GitHub's "Require status checks to pass
before merging" setting. As a result, PRs that didn't trigger all
workflows couldn't be merged, because GitHub waited for the skipped
workflows to finish.
`dorny/paths-filter` is a somewhat elegant workaround proposed in
https://stackoverflow.com/questions/66751567.
* dev: run workflows only if certain file paths change
* fix: looks like you can't ? a /
* feat: simpler approach
Don't run Rust if only package.json, package-lock.json or anything under
web/packages has changed.
Don't run either if they only have docs changes.
Also bump its helper crates (js-sys, wasm-bindgen-futures) to the
latest versions, except for web-sys which seems to be locked by wgpu
to one version before the latest (0.3.50).
Appending the build date doesn't work (the Mozilla verison format
requires each numeric to be <65536). Use GITHUB_RUN_NUMBER instead,
which increases each time the workflow runs.
David Wendt