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
* Update CODEOWNERS: remove requirement for supply-chain team to approve lavamoat policy changes
* Require extension-devs or supply-chain teams to give approving reviews on PRs that have lavamoat policy changes
---------
Co-authored-by: Brad Decker <bhdecker84@gmail.com>
* 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>
In order to properly review a pull request, it is necessary to not only
understand the details about the changes presented, but also the
*context* behind those changes. Oftentimes, this context is difficult to
locate or even absent altogether. Providing a link to an issue or a user
story helps, but only if there are sufficient details listed in the
resource itself, which may not always be the case. Ultimately, I feel
that the best way to provide such information is to briefly explain it
in the PR description.
Additionally, for changes that involve UI/UX improvements, screenshots
or screencaps can really help the review process, as one can comprehend
the changes much faster than reading the relevant code.
With that in mind, this commit updates the pull request template to
include some more prompts and a better template for the description
area.
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.
