The `metamaskbot` account now comments with a failure message when the
policy update fails. This comment also includes a link to the specific
run that failed, so that the PR author can review the log and/or retry
the policy update.
Today if you try to re-run failed jobs in a policy update, it will
fail to restore caches from jobs that were successful. This could
result in a partial update, or a misleading "No policy changes"
message when there are policy changes to make. It's only safe to re-
run the entire workflow.
The cache key has been updated to reference the commit hash instead of
the run ID, making it safe to re-run just the failed jobs.
If there is a cache miss during the policy update workflow, the result
would be invalid (either a partial update or a misleading "no policy
changes" message). To prevent this, the cache step will now fail if it
is not able to restore the cache.
The update lavamoat policies workflow was installing dependencies from
the `develop` branch rather than the PR. This resulted in invalid
policy updates. It has been updated to use the PR branch in each step
instead.
This GitHub action workflow was disabled, but was still running setup
steps. It has now been removed entirely. We can re-introduce it again
later once the problem that led to it being disabled has been fixed.
The associated npm script and JavaScript module have been removed as
well.
GitHub actions that install dependencies will now also cache those
dependencies using the standard strategy for Yarn (which is to hash the
lockfile).
This matches the module template (see https://github.com/MetaMask/metamask-module-template/pull/145
for details).
This should have no functional impact except that this action will run
faster when dependencies are unchanged.
A bot command has been added that can update LavaMoat policies
automatically. This helps contributors without a Linux machine to
produce policy files that match exactly what CI expects.
The README has been updated with instructions for this new workflow.
* Lint GitHub Action workflows
We now lint GitHub Action workflows. This lint step is performed in the
`main` workflow, which has an "All jobs passed" check that we can add
further checks to in the future. This can grow to encompass all PR
status checks that depend upon the PR contents.
This workflow is based upon the one used in the MetaMask module
template.
* Fix branch names
* Fix lint error
The fitness function workflow now uses an immutable install, ensuring
that the dependencies installed are known and tracked in the lockfile.
This makes it easier to audit exactly which dependencies were used for
each run.
The `chmod` step has been removed from the GitHub Actions workflow for
adding release labels. The script has been made executable in the
repository instead (the file mode is tracked by git).
The `nvmrc` file is now referenced in our GitHub Actions workflows,
rather than hard-coding the expected Node.js version. This will make
future Node.js version changes easier to manage.
* feat(action): github action to add release label when PR gets merged
* feat(action): make sure the action only runs for PRs merged in main branch
* fix(action): update labels default color
* fix(action): add check on release label format
* fix(action): type function explicitely
* feat(action): add possibility to extract next release version number from artifact
* fix(action): rename next rc cut number into next semver version
* feat(action): add a github action to create release branch
* fix(action): default branch is develop
* fix(action): specify name of workflow used to create release branch
* fix(action): handle case where artifact doesn't exist
* fix(action): create branch but not the PR
* feat(action): fetch next semver version from release branches name or from package.json
* fix(action): remove unused Create Release Branch action
* fix(action): release branch format was not correct
* feat(action): take tags into account when calculating next version number
* feat(action): add the possibility to force next semver version
* fix(action): update comments
* fix(action): adopt kebak-case instead of snake_case
* fix(action): rename PERSONAL_ACCESS_TOKEN into RELEASE_LABEL_TOKEN
* fix(action): yarn installation not required
* fix(action): yarn install shall be immutable
* fix(action): make the script compatible with ShellCheck
* fix(script): exit script earlier if condition is met
* fix(action): use closingIssuesReferences instead of timeline events
* fix(action): add execute permissions to script
* fix(action): remove duplicate comment
* chore: add action to trigger metamask-desktop ci
We want to be able to trigger
MetaMask Desktop CI whenever we
are releasing the Extension (in this
case, merging to master branch).
This will allow the desktop team
to easily identify whenever a breaking
change (to the extension-desktop app
pairing) is being released and address
the issue within the desktop app
in a timely manner
* use double quotes
ensure these get interpreted as single strings.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
---------
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
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.
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.
