The Playwright install step run in the `test-storybook` job has been
updated to ensure that we are running the correct install command.
Previously we were using `yarn dlx`, which would use the latest version
of `Playwright` rather than the one currently installed. Instead now we
are using `yarn exec`, which will invoke the `playwright` binary from
the locally installed package. This binary has an `install` command
that completes the necessary setup, which is to install custom patched
browsers for Playwright to run.
* added storybook test runner
* added test runner in ci
* updated test for ci and fixed lint error
* updated lavamoat policy
* updated test command
* updated playwright
* changed command to storybook;ci
* updated command
* updated instance for test-storybook
* updated playwright
* added playwright step
* replaced concurrently with start-server-and-test
* updated the static storybook directory
* replaced first with last
* updated lock file
* replaced first with last
* updated test-storybook with maxworkers
* updated .depchechrc
* updated yml
* removed id from banner base
* replaced broken stories with .stories-to-do.js extesnsion
* updated token allowance story
* removed duplicacies from yarn
* fixed lavamoat
* removed filename comment
* updated links for docs
* fixed file extension for stories
* updated path for stories.json
* updated stories.json path
* yarn updated
* updated stories
* updated yarn
* updated wait on
* First e2e mv3 specific dapp testcase
* Fix testpath for snaps
* Update `it` description
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* e2e test paths improvement
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Migrate to new controller packages
`@metamask/controllers` is deprecated, and most of the controllers that
lived here are now located in their own package ([1]). This commit
replaces `@metamask/controllers` in `package.json` with references to
these packages and updates `import` lines to match.
[1]: https://github.com/MetaMask/controllers/pull/831
* Support GitHub registry for draft PRs (#16549)
* Add additional allowed host to lockfile linter
* Update LavaMoat policies
* Add policy exception for nanoid
* Add additional nanoid overrides
* Update LavaMoat policies again
* Bump controller packages
* Update lavamoat
* Bump controller packages
* Update packages to v1.0.0
* Expand gitignore comment
* Unpin controller dependencies, using ^ range instead
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The bundle size diff message is using the wrong point of comparision,
leading to misleading results on feature branches that have been
merged with `develop` since they were created.
When this feature was introduced, we went back and forth a few times on
what we should be comparing the branch with to get an accurate bundle
size comparison.
The first attempt used `develop` as the point of comparison, but that
didn't work because it was a moving target, and because it didn't
reflect the changes made on this branch. As bundle increases or
decreases were added on `develop`, they would alter the diff on each
feature PR.
Then we chose to use the fork-point of the branch, the commit of
`develop` that the branch forked off of. This works for feature
branches that don't merge in `develop`. But the minute `develop` gets
merged in, then unrelated changes on `develop` affect the measurement.
The _most recent_ commit from `develop` on the current branch is a
better comparison. Any difference between this commit and the feature
branch in terms of bundle size would be attributable to the feature
branch changes. This is what `merge-base` gives us.
* Ensure prod beta build is created when merging to master
* Fix: remove negation
* Update .circleci/config.yml
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Add filter tag
* Fix tag
* test tag
* fix
* Changed tag
* Add test-e2e-chrome
* Filter by branch instead of tag
* Move tests to correct mv3 folder
* Remove ignore from e2e regular chrome job
* Remove filter, so it's run on all PRs
* Handling red X for MV3 e2e failures
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The CI job for building storybook will fail occasionally, presumably
due to a Node.js process running out of heap memory. This job is the
only build job that runs with default Node.js memory settings.
It has been updated to use a larger instance size and to set the heap
size to 2GB, matching our other build jobs.
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes#15003
This PR converts `generate-lavamoat-policies.sh` to `.js` using Yargs. This makes it easier to only generate policy files for a specific build type (using the `-t` flag), which is often useful during Flask development. In addition, the `lavamoat:background:auto` scripts are renamed, and the main readme is updated with some useful tips.
Note that `lavamoat:background:auto:dev` is removed and `lavamoat:background:auto` should be used during local development.
* User actions benchmark and artifacts
* Lint and fix identation
* Fix lint
* Updated path
* lint
* Add user actions benchmark to pre release job
* Remove title
* Out path updated
* See if url is finally fixed
* Adding some console logs
* lint
* fix lint
* fix lint
* Updated persisting and store artifacts path
* Added MetaMask bot correct link and remove console logs
* Remove console log
* Sort Imports
* Fix lint
* Update loadAccount function and prop name for clarity to loadNewAccount
* Run yarn setup
* Fix yarn
* Update Create Account element for Create account
* Remove unnecessary step on send
Co-authored-by: Jyoti Puri <jyotipuri@gmail.com>
An improper deploy key was used to deploy the TypeScript
migration dashboard. A new key has been created on the GitHub side for
the `metamask-extension-ts-migration-dashboard` repo and also added to
CircleCI. The new fingerprint for this key is provided in this commit.
This should hopefully make it possible for us to deploy to this repo
from CircleCI.
When the TypeScript migration dashboard is updated, it is built and
deployed in another repo, which is then deployed via GitHub Pages. To
push to this repo we have to set a Git username and email. This is
missing from the CircleCI config, so this commit uses the metamaskbot
GitHub account to do that.
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
