Use `secrets.METAMASKBOT_CROWDIN_TOKEN` for `GITHUB_TOKEN`
ref: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow
> When you use the repository's GITHUB_TOKEN to perform tasks on behalf of the GitHub Actions app, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
The CLA bot had its write permissions revoked recently when our
organization-wide settings were updated to restrict actions to read
access by default. This PR restores write access to PRs and to the
repository itself for the CLA bot. It needs PR write access to leave
comments, and needs write access to the repo itself to commit new
signatures.
This change adds a GitHub Dependabot configuration to enable daily checks for dependency updates.
[See the docs for more information.][1]
[1]:https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates
This config enables checking for dependencies in the root `package.json` file (`directory`) every weekday (`schedule.interval`) only for lockfile updates, ignoring any new versions that would require package manifest changes. (if necessary, `versioning-strategy`). This is all restricted to the organization's `@metamask/*` packages.
The CLA signature bot will check the authors of each PR to ensure they
have all signed the CLA. If any authors still need to sign the CLA, it
will leave a comment explaining how it can be signed, and will check
back upon each comment to see if it has been signed.
The bot used is `MetaMask/cla-signature-bot`, which is a fork of
`Roblox/cla-signature-bot`. The fork has a couple of improvements, and
it updated the PR comment text to be more appropriate for our usage.
Currently the only user on the `allowlist` is `dependabot`, but any public
members of the MetaMask organization will also be exempt from needing
to sign the CLA due to the `allow-organization-members` setting.
The signatures are stored in `cla.json` on the `cla-signatures` branch,
which is in this repository as a distinct root. We can consider moving
this to a separate repository in the future - this was just easier to
setup.
* ci - install deps - limit install scripts to those needed for build
* Update .circleci/scripts/deps-install.sh
Co-Authored-By: Mark Stacey <markjstacey@gmail.com>
* ci - install deps - expand install scripts needed for tests
* ci - install deps - expand install scripts needed for integration tests
* ci - install deps - fix node-sass script ref
* github - set codeowners for scripts/deps-install
* development - add utility to show deps with install scripts
* lint fix
* deps - move read-installed to devDeps
As a solution to the constant lockfile churn issues we've had with
`npm`, the project now uses `yarn` to manage dependencies.
The `package-lock.json` file has been replaced with `yarn.lock`, which
was created using `yarn import`. It should approximate the contents of
`package-lock.json` fairly well, though there may be some changes due to
deduplication. The codeowners file has been updated to reference this
new lockfile.
All documentation and npm scripts have been updated to reference `yarn`
rather than `npm`. Note that running scripts using `npm run` still works
fine, but it seemed better to switch those to `yarn` as well to avoid
confusion.
The `npm-audit` Bash script has been replaced with `yarn-audit`. The
output of `yarn audit` is a bit different than `npm audit` in that it
returns a bitmask to describe which severity issues were found. This
made it simpler to check the results directly from the Bash script, so
the associated `npm-audit-check.js` script was no longer required. The
output should be exactly the same, and the information is still sourced
from the same place (the npm registry).
The new `yarn-audit` script does have an external dependency: `jq`.
However, `jq` is already assumed to be present by another CI script, and
is present on all CI images we use. `jq` was not added to `package.json`
as a dependency because there is no official package on the npm
registry, just wrapper scripts. We don't need it anywhere exept on CI
anyway.
The section in `CONTRIBUTING` about how to develop inside the
`node_modules` folder was removed, as the advice was a bit dated, and
wasn't specific to this project anyway.
