A Metamask fork with Infura removed and default networks editable
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
ciphermask/.circleci/config.yml

924 lines
25 KiB

version: 2.1
executors:
node-browsers:
docker:
- image: circleci/node:16-browsers
node-browsers-medium-plus:
docker:
- image: circleci/node:16-browsers
resource_class: medium+
environment:
NODE_OPTIONS: --max_old_space_size=2048
shellcheck:
docker:
- image: koalaman/shellcheck-alpine@sha256:dfaf08fab58c158549d3be64fb101c626abc5f16f341b569092577ae207db199
workflows:
test_and_release:
jobs:
- create_release_pull_request:
requires:
- prep-deps
filters:
branches:
only:
- /^Version-v(\d+)[.](\d+)[.](\d+)/
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- test-deps-audit:
requires:
- prep-deps
- test-deps-depcheck:
requires:
- prep-deps
- test-yarn-dedupe:
requires:
- prep-deps
- validate-lavamoat-config:
filters:
branches:
only:
- /^Version-v(\d+)[.](\d+)[.](\d+)|master/
requires:
- prep-deps
- prep-build:
requires:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- prep-build-beta:
requires:
- prep-deps
- prep-build-flask:
requires:
- prep-deps
- prep-build-test:
requires:
- prep-deps
- prep-build-test-mv3:
requires:
- prep-deps
- prep-build-test-flask:
requires:
- prep-deps
- test-storybook:
requires:
- prep-deps
- prep-build-storybook:
requires:
- test-storybook
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
- prep-build-ts-migration-dashboard:
requires:
- prep-deps
- test-lint:
requires:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- test-lint-shellcheck
- test-lint-lockfile:
requires:
- prep-deps
- test-lint-changelog:
requires:
- prep-deps
- test-e2e-chrome:
requires:
- prep-build-test
- test-e2e-firefox:
requires:
- prep-build-test
- test-e2e-chrome-snaps:
requires:
- prep-build-test-flask
- test-e2e-firefox-snaps:
requires:
- prep-build-test-flask
- test-unit:
requires:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- test-unit-global:
requires:
- prep-deps
- validate-source-maps:
requires:
- prep-build
- validate-source-maps-beta:
requires:
- prep-build-beta
- validate-source-maps-flask:
requires:
- prep-build-flask
- test-mozilla-lint:
requires:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- prep-build
- test-mozilla-lint-beta:
requires:
- prep-deps
- prep-build-beta
- test-mozilla-lint-flask:
requires:
- prep-deps
- prep-build-flask
- all-tests-pass:
requires:
- validate-lavamoat-config
- test-lint
- test-lint-shellcheck
- test-lint-lockfile
- test-lint-changelog
- test-unit
- test-unit-global
- validate-source-maps
- validate-source-maps-beta
- validate-source-maps-flask
- test-mozilla-lint
- test-mozilla-lint-beta
- test-mozilla-lint-flask
- test-e2e-chrome
- test-e2e-firefox
- test-e2e-chrome-snaps
- test-e2e-firefox-snaps
- benchmark:
requires:
- prep-build-test
- user-actions-benchmark:
requires:
- prep-build-test
- stats-module-load-init:
requires:
- prep-build-test-mv3
- job-publish-prerelease:
requires:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- prep-build
- prep-build-beta
- prep-build-flask
- prep-build-storybook
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
- prep-build-ts-migration-dashboard
- prep-build-test-mv3
- benchmark
- user-actions-benchmark
- stats-module-load-init
- all-tests-pass
- job-publish-release:
filters:
branches:
only: master
requires:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
- prep-deps
- prep-build
- prep-build-flask
- all-tests-pass
- job-publish-storybook:
filters:
branches:
only: develop
requires:
- prep-build-storybook
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
- job-publish-ts-migration-dashboard:
filters:
branches:
only: develop
requires:
- prep-build-ts-migration-dashboard
jobs:
create_release_pull_request:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Bump manifest version
command: .circleci/scripts/release-bump-manifest-version.sh
- run:
name: Update changelog
command: yarn update-changelog --rc
- run:
name: Commit changes
command: .circleci/scripts/release-commit-version-bump.sh
- run:
name: Create GitHub Pull Request for version
command: .circleci/scripts/release-create-release-pr.sh
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
prep-deps:
executor: node-browsers
steps:
- checkout
- restore_cache:
key: dependency-cache-v1-{{ checksum "yarn.lock" }}
- run:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
name: Install deps
command: |
.circleci/scripts/deps-install.sh
- save_cache:
key: dependency-cache-v1-{{ checksum "yarn.lock" }}
paths:
- node_modules/
- build-artifacts/yarn-install-har/
- run:
name: Postinstall
command: |
yarn setup:postinstall
- persist_to_workspace:
root: .
paths:
- node_modules
- build-artifacts
validate-lavamoat-config:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Validate allow-scripts config
command: |
.circleci/scripts/validate-allow-scripts.sh
- run:
name: Validate LavaMoat policy
command: |
.circleci/scripts/validate-lavamoat-policy.sh
prep-build:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: build:dist
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
command: yarn dist
- run:
name: build:debug
command: find dist/ -type f -exec md5sum {} \; | sort -k 2
- persist_to_workspace:
root: .
paths:
- dist
- builds
prep-build-beta:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: build:dist
command: yarn build --build-type beta prod
- run:
name: build:debug
command: find dist/ -type f -exec md5sum {} \; | sort -k 2
- run:
name: Move beta build to 'dist-beta' to avoid conflict with production build
command: mv ./dist ./dist-beta
- run:
name: Move beta zips to 'builds-beta' to avoid conflict with production build
command: mv ./builds ./builds-beta
- persist_to_workspace:
root: .
paths:
- dist-beta
- builds-beta
prep-build-flask:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: build:dist
command: yarn build --build-type flask prod
- run:
name: build:debug
command: find dist/ -type f -exec md5sum {} \; | sort -k 2
- run:
name: Move flask build to 'dist-flask' to avoid conflict with production build
command: mv ./dist ./dist-flask
- run:
name: Move flask zips to 'builds-flask' to avoid conflict with production build
command: mv ./builds ./builds-flask
- persist_to_workspace:
root: .
paths:
- dist-flask
- builds-flask
prep-build-test-flask:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Build extension for testing
command: yarn build:test:flask
- run:
name: Move test build to 'dist-test' to avoid conflict with production build
command: mv ./dist ./dist-test-flask
- run:
name: Move test zips to 'builds-test' to avoid conflict with production build
command: mv ./builds ./builds-test-flask
- persist_to_workspace:
root: .
paths:
- dist-test-flask
- builds-test-flask
prep-build-test-mv3:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Build extension in mv3 for testing
command: yarn build:test:mv3
- run:
name: Move test build to 'dist-test' to avoid conflict with production build
command: mv ./dist ./dist-test-mv3
- run:
name: Move test zips to 'builds-test' to avoid conflict with production build
command: mv ./builds ./builds-test-mv3
- persist_to_workspace:
root: .
paths:
- dist-test-mv3
- builds-test-mv3
prep-build-test:
executor: node-browsers-medium-plus
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Build extension for testing
command: yarn build:test
- run:
name: Move test build to 'dist-test' to avoid conflict with production build
command: mv ./dist ./dist-test
- run:
name: Move test zips to 'builds-test' to avoid conflict with production build
command: mv ./builds ./builds-test
- persist_to_workspace:
root: .
paths:
- dist-test
- builds-test
prep-build-storybook:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Build Storybook
command: yarn storybook:build
- persist_to_workspace:
root: .
paths:
- storybook-build
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
prep-build-ts-migration-dashboard:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Build TypeScript migration dashboard
command: yarn ts-migration:dashboard:build
- persist_to_workspace:
root: .
paths:
- development/ts-migration-dashboard/build
test-storybook:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Test Storybook
command: yarn storybook:test
test-yarn-dedupe:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Detect yarn lock deduplications
command: yarn yarn-deduplicate && git diff --exit-code yarn.lock
test-lint:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Lint
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
command: yarn lint
- run:
name: Verify locales
command: yarn verify-locales --quiet
test-lint-shellcheck:
executor: shellcheck
steps:
- checkout
- run: apk add --no-cache bash jq yarn
- run:
name: ShellCheck Lint
command: ./development/shellcheck.sh
test-lint-lockfile:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: lockfile-lint
command: yarn lint:lockfile
test-lint-changelog:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- when:
condition:
not:
matches:
pattern: /^Version-v(\d+)[.](\d+)[.](\d+)$/
value: << pipeline.git.branch >>
steps:
- run:
name: Validate changelog
command: yarn lint:changelog
- when:
condition:
matches:
pattern: /^Version-v(\d+)[.](\d+)[.](\d+)$/
value: << pipeline.git.branch >>
steps:
- run:
name: Validate release candidate changelog
command: yarn lint:changelog:rc
test-deps-audit:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
name: yarn audit
command: .circleci/scripts/yarn-audit.sh
test-deps-depcheck:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: depcheck
command: yarn depcheck
test-e2e-chrome:
executor: node-browsers
steps:
- checkout
- run:
name: Re-Install Chrome
command: ./.circleci/scripts/chrome-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test ./builds
- run:
name: test:e2e:chrome
command: |
if .circleci/scripts/test-run-e2e.sh
then
yarn test:e2e:chrome --retries 2
fi
no_output_timeout: 20m
- store_artifacts:
path: test-artifacts
destination: test-artifacts
test-e2e-firefox-snaps:
executor: node-browsers
steps:
- checkout
- run:
name: Install Firefox
command: ./.circleci/scripts/firefox-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test-flask ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test-flask ./builds
- run:
name: test:e2e:firefox:snaps
command: |
if .circleci/scripts/test-run-e2e.sh
then
yarn test:e2e:firefox:snaps --retries 2
fi
no_output_timeout: 20m
- store_artifacts:
path: test-artifacts
destination: test-artifacts
test-e2e-chrome-snaps:
executor: node-browsers
steps:
- checkout
- run:
name: Re-Install Chrome
command: ./.circleci/scripts/chrome-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test-flask ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test-flask ./builds
- run:
name: test:e2e:chrome:snaps
command: |
if .circleci/scripts/test-run-e2e.sh
then
yarn test:e2e:chrome:snaps --retries 2
fi
no_output_timeout: 20m
- store_artifacts:
path: test-artifacts
destination: test-artifacts
test-e2e-firefox:
executor: node-browsers-medium-plus
steps:
- checkout
- run:
name: Install Firefox
command: ./.circleci/scripts/firefox-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test ./builds
- run:
name: test:e2e:firefox
command: |
if .circleci/scripts/test-run-e2e.sh
then
yarn test:e2e:firefox --retries 2
fi
no_output_timeout: 20m
- store_artifacts:
path: test-artifacts
destination: test-artifacts
benchmark:
executor: node-browsers-medium-plus
steps:
- checkout
- run:
name: Re-Install Chrome
command: ./.circleci/scripts/chrome-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test ./builds
- run:
name: Run page load benchmark
command: yarn benchmark:chrome --out test-artifacts/chrome/benchmark/pageload.json --retries 2
- store_artifacts:
path: test-artifacts
destination: test-artifacts
- persist_to_workspace:
root: .
paths:
- test-artifacts
user-actions-benchmark:
executor: node-browsers-medium-plus
steps:
- checkout
- run:
name: Re-Install Chrome
command: ./.circleci/scripts/chrome-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test ./builds
- run:
name: Run page load benchmark
command: yarn user-actions-benchmark:chrome --out test-artifacts/chrome/benchmark/user_actions.json --retries 2
- store_artifacts:
path: test-artifacts
destination: test-artifacts
- persist_to_workspace:
root: .
paths:
- test-artifacts
stats-module-load-init:
executor: node-browsers-medium-plus
steps:
- checkout
- run:
name: Re-Install Chrome
command: ./.circleci/scripts/chrome-install.sh
- attach_workspace:
at: .
- run:
name: Move test build to dist
command: mv ./dist-test-mv3 ./dist
- run:
name: Move test zips to builds
command: mv ./builds-test-mv3 ./builds
- run:
name: Run page load benchmark
command: |
mkdir -p test-artifacts/chrome/mv3
cp -R development/charts/flamegraph test-artifacts/chrome/mv3/initialisation
cp -R development/charts/flamegraph/chart test-artifacts/chrome/mv3/initialisation/background
cp -R development/charts/flamegraph/chart test-artifacts/chrome/mv3/initialisation/ui
cp -R development/charts/table test-artifacts/chrome/mv3/load_time
- run:
name: Run page load benchmark
command: yarn mv3:stats:chrome --out test-artifacts/chrome/mv3
Bundlesize stats over time (#15209) * Adding tasks for MV3 test build * more changes * fix * fix * fix * MV3 CI fixes * fixes * fix * Initial work to capture the logs, write to file, and parse it. Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * chrome debug logs * Pull logs from webdriver and save to json file. Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * comment out stats stuffs Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * Lint Fixes Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * Remove console.log Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * fixes * Adding build artifact for initialisation time * change * fix lint * fix * fix * fix * fix * fixes * Capturing load time stats * fix * fix * fix * fix * fix build * fix * fix * fix * fix * fix * Initial work to capture the logs, write to file, and parse it. Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * chrome debug logs * Pull logs from webdriver and save to json file. Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * comment out stats stuffs Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * Lint Fixes Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * Remove console.log Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * fix * fix * fix * fix * Initial work to capture the logs, write to file, and parse it. Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> chrome debug logs Pull logs from webdriver and save to json file. Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> Remove console.log Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> split output of lavamoat to 2 files. background and ui Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * fix * fix * fix * Enable logging to chrome_debug only if in MV3 Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> * fix * fix * fix * fixes * fix * fix * fix * fix * fixes * test * test * fix * fix * MV3 bundle size stats * fix * Committing bundle size status to extension_bundlesize_stats repo * fix * fix * fix * fix * fix * fix * fix * fix * fix * fix * Initial commit * Initial commit * Initial commit * Initial commit * fixes * fix * fix * fix * fix * fix * fix Co-authored-by: Akintayo A. Olusegun <akintayo.segun@gmail.com> Co-authored-by: PeterYinusa <peter.yinusa@consensys.net>
2 years ago
- run:
name: Record bundle size at commit
command: ./.circleci/scripts/bundle-stats-commit.sh
- store_artifacts:
path: test-artifacts
destination: test-artifacts
- persist_to_workspace:
root: .
paths:
- test-artifacts
job-publish-prerelease:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: build:source-map-explorer
command: ./development/source-map-explorer.sh
- store_artifacts:
path: dist/sourcemaps
destination: builds/sourcemaps
- store_artifacts:
path: dist-beta/sourcemaps
destination: builds-beta/sourcemaps
- store_artifacts:
path: dist-flask/sourcemaps
destination: builds-flask/sourcemaps
- store_artifacts:
path: builds
destination: builds
- store_artifacts:
path: builds-beta
destination: builds-beta
- store_artifacts:
path: builds-flask
destination: builds-flask
- store_artifacts:
path: coverage
destination: coverage
- store_artifacts:
path: jest-coverage
destination: jest-coverage
- store_artifacts:
path: test-artifacts
destination: test-artifacts
# important: generate lavamoat viz AFTER uploading builds as artifacts
# Temporarily disabled until we can update to a version of `sesify` with
# this fix included: https://github.com/LavaMoat/LavaMoat/pull/121
- run:
name: build:lavamoat-viz
command: ./.circleci/scripts/create-lavamoat-viz.sh
- store_artifacts:
path: build-artifacts
destination: build-artifacts
- store_artifacts:
path: storybook-build
destination: storybook
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
- store_artifacts:
path: development/ts-migration-dashboard/build
destination: ts-migration-dashboard
- run:
name: build:announce
command: ./development/metamaskbot-build-announce.js
job-publish-release:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Publish main release to Sentry
command: yarn sentry:publish
- run:
name: Publish Flask release to Sentry
command: yarn sentry:publish --build-type flask
- run:
name: Create GitHub release
command: |
.circleci/scripts/release-create-gh-release.sh
job-publish-storybook:
executor: node-browsers
steps:
- add_ssh_keys:
fingerprints:
- '3d:49:29:f4:b2:e8:ea:af:d1:32:eb:2a:fc:15:85:d8'
- checkout
- attach_workspace:
at: .
- run:
name: storybook:deploy
command: |
git remote add storybook git@github.com:MetaMask/metamask-storybook.git
yarn storybook:deploy
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
job-publish-ts-migration-dashboard:
executor: node-browsers
steps:
- add_ssh_keys:
fingerprints:
- "8b:21:e3:20:7c:c9:db:82:74:2d:86:d6:11:a7:2f:49"
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
- checkout
- attach_workspace:
at: .
- run:
name: ts-migration-dashboard:deploy
command: |
git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git
git config user.name "MetaMask Bot"
git config user.email metamaskbot@users.noreply.github.com
Add TypeScript migration dashboard (#13820) As we convert parts of the codebase to TypeScript, we will want a way to track progress. This commit adds a dashboard which displays all of the files that we wish to convert to TypeScript and which files we've already converted. The list of all possible files to convert is predetermined by walking the dependency graph of each entrypoint the build system uses to compile the extension (the files that the entrypoint imports, the files that the imports import, etc). The list should not need to be regenerated, but you can do it by running: yarn ts-migration:enumerate The dashboard is implemented as a separate React app. The CircleCI configuration has been updated so that when a new commit is pushed, the React app is built and stored in the CircleCI artifacts. When a PR is merged, the built files will be pushed to a separate repo whose sole purpose is to serve the dashboard via GitHub Pages (this is the same way that the Storybook works). All of the app code and script to build the app are self-contained under `development/ts-migration-dashboard`. To build this app yourself, you can run: yarn ts-migration:dashboard:build or if you want to build automatically as you change files, run: yarn ts-migration:dashboard:watch Then open the following file in your browser (there is no server component): development/ts-migration-dashboard/build/index.html Finally, although you shouldn't have to do this, to manually deploy the dashboard once built, you can run: git remote add ts-migration-dashboard git@github.com:MetaMask/metamask-extension-ts-migration-dashboard.git yarn ts-migration:dashboard:deploy
2 years ago
yarn ts-migration:dashboard:deploy
test-unit:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
Permission System 2.0 (#12243) # Permission System 2.0 ## Background This PR migrates the extension permission system to [the new `PermissionController`](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions). The original permission system, based on [`rpc-cap`](https://github.com/MetaMask/rpc-cap), introduced [`ZCAP-LD`](https://w3c-ccg.github.io/zcap-ld/)-like permissions to our JSON-RPC stack. We used it to [implement](https://github.com/MetaMask/metamask-extension/pull/7004) what we called "LoginPerSite" in [version 7.7.0](https://github.com/MetaMask/metamask-extension/releases/tag/v7.7.0) of the extension, which enabled the user to choose which accounts, if any, should be exposed to each dapp. While that was a worthwhile feature in and of itself, we wanted a permission _system_ in order to enable everything we are going to with Snaps. Unfortunately, the original permission system was difficult to use, and necessitated the creation of the original `PermissionsController` (note the "s"), which was more or less a wrapper for `rpc-cap`. With this PR, we shake off the yoke of the original permission system, in favor of the modular, self-contained, ergonomic, and more mature permission system 2.0. Note that [the `PermissionController` readme](https://github.com/MetaMask/snaps-skunkworks/tree/main/packages/controllers/src/permissions/README.md) explains how the new permission system works. The `PermissionController` and `SubjectMetadataController` are currently shipped via `@metamask/snap-controllers`. This is a temporary state of affairs, and we'll move them to `@metamask/controllers` once they've landed in prod. ## Changes in Detail First, the changes in this PR are not as big as they seem. Roughly half of the additions in this PR are fixtures in the test for the new migration (number 68), and a significant portion of the remaining ~2500 lines are due to find-and-replace changes in other test fixtures and UI files. - The extension `PermissionsController` has been deleted, and completely replaced with the new `PermissionController` from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers). - The original `PermissionsController` "domain metadata" functionality is now managed by the new `SubjectMetadataController`, also from [`@metamask/snap-controllers`](https://www.npmjs.com/package/@metamask/snap-controllers). - The permission activity and history log controller has been renamed `PermissionLogController` and has its own top-level state key, but is otherwise functionally equivalent to the existing implementation. - Migration number 68 has been added to account for the new state changes. - The tests in `app/scripts/controllers/permissions` have been migrated from `mocha` to `jest`. Reviewers should focus their attention on the following files: - `app/scripts/` - `metamask-controller.js` - This is where most of the integration work for the new `PermissionController` occurs. Some functions that were internal to the original controller were moved here. - `controllers/permissions/` - `selectors.js` - These selectors are for `ControllerMessenger` selector subscriptions. The actual subscriptions occur in `metamask-controller.js`. See the `ControllerMessenger` implementation for details. - `specifications.js` - The caveat and permission specifications are required by the new `PermissionController`, and are used to specify the `eth_accounts` permission and its JSON-RPC method implementation. See the `PermissionController` readme for details. - `migrations/068.js` - The new state should be cross-referenced with the controllers that manage it. The accompanying tests should also be thoroughly reviewed. Some files may appear new but have just moved and/or been renamed: - `app/scripts/lib/rpc-method-middleware/handlers/request-accounts.js` - This was previously implemented in `controllers/permissions/permissionsMethodMiddleware.js`. - `test/mocks/permissions.js` - A truncated version of `test/mocks/permission-controller.js`. Co-authored-by: Mark Stacey <markjstacey@gmail.com>
3 years ago
name: test:coverage:mocha
command: yarn test:coverage:mocha
- run:
name: test:coverage:jest
command: yarn test:coverage:jest
- run:
name: Validate coverage thresholds
command: |
if ! git diff --exit-code jest.config.js development/jest.config.js; then
echo "Detected changes in coverage thresholds"
exit 1
fi
- persist_to_workspace:
root: .
paths:
- .nyc_output
- coverage
- jest-coverage
test-unit-global:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: test:unit:global
command: yarn test:unit:global
validate-source-maps:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Validate source maps
command: yarn validate-source-maps
validate-source-maps-beta:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Move beta build to dist
command: mv ./dist-beta ./dist
- run:
name: Move beta zips to builds
command: mv ./builds-beta ./builds
- run:
name: Validate source maps
command: yarn validate-source-maps
validate-source-maps-flask:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Move flask build to dist
command: mv ./dist-flask ./dist
- run:
name: Move flask zips to builds
command: mv ./builds-flask ./builds
- run:
name: Validate source maps
command: yarn validate-source-maps
test-mozilla-lint:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: test:mozilla-lint
Switch from `npm` to `yarn` (#6843) 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.
5 years ago
command: NODE_OPTIONS=--max_old_space_size=3072 yarn mozilla-lint
test-mozilla-lint-beta:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Move beta build to dist
command: mv ./dist-beta ./dist
- run:
name: Move beta zips to builds
command: mv ./builds-beta ./builds
- run:
name: test:mozilla-lint
command: NODE_OPTIONS=--max_old_space_size=3072 yarn mozilla-lint
test-mozilla-lint-flask:
executor: node-browsers
steps:
- checkout
- attach_workspace:
at: .
- run:
name: Move flask build to dist
command: mv ./dist-flask ./dist
- run:
name: Move flask zips to builds
command: mv ./builds-flask ./builds
- run:
name: test:mozilla-lint
command: NODE_OPTIONS=--max_old_space_size=3072 yarn mozilla-lint
all-tests-pass:
executor: node-browsers
steps:
- run:
name: All Tests Passed
command: echo 'weew - everything passed!'