The changelog script now accepts an `--rc` flag to tell it whether to
add new changes to `Unreleased` or to the header for the current
version.
Previously this was inferred from whether the current version matched
the most recent tag. However this method only works for the first
update. Using a flag simplifies this logic, and makes it possible to
manually re-run this for further updates to a release candidate.
The changelog will now be automatically updated when a release branch
is created. A new release header along with changelog entries for any
new commits will be added.
Note that this changelog will still need to be manually cleaned up, but
it's one less manual step at least.
The old Bash script for adding a new release header to the changelog
has been removed, as that functionality is now built into the changelog
update script.
A new script has been added to commit any changes made to the manifest
and changelog. This step used to happen at the end of the bump manifest
version script, but now the changelog update relies upon the manifest
version bump happening first, so it needed to be re-ordered. The
changes should only be committed on the first run of the branch, as
it's contingent upon the manifest changing (due to the version bump).
Further changelog updates won't trigger new automatic commits.
The script responsible for creating the "Sync `master` with `develop`"
PR has been removed. We will soon be eliminating the need for a
`master` branch altogether, so we don't need this anymore. Also, this
script hasn't been running correctly in a long time. We've been
creating this PR manually.
New changelog release headers now omit the date. These headers are
added automatically when a new release branch is created, and that
rarely ends up being the actual date of the release, so these dates
have all been inaccurate anyway.
The date will be re-added to the changelog later as part of a new
script, after a release has been published.
The CI script to ensure no LavaMoat policy changes are required has
been failing despite there being no changes. It turns out that the
command used to check for changes (`git diff-index`) was failing
despite the lack of changes because the file was written again by
`yarn lavamoat:auto` but git hadn't gotten around to updating its index
since the write occurred, so it was considering it as changed until it
verified it wasn't [1].
The command has been replaced by `git diff --exit-code --quiet`, which
should do exactly the same thing except that it forces git to update
its internal cache to verify whether changes are present.
[1]: https://stackoverflow.com/questions/34807971/why-does-git-diff-index-head-result-change-for-touched-files-after-git-diff-or-g
A CI job has been added to ensure the `allow-scripts` config and the
LavaMoat auto-generated policy is up-to-date. This will only run on
release branches and the `master` branch, because it's too difficult a
requirement to meet for each PR for contributors on macOS, due to
differences in the dependency graph caused by optional dependencies.
The `allow-scripts` and LavaMoat policy have both been updated using
`yarn allow-scripts auto` and `yarn lavamoat:auto`.
The `.sh` file extension is now used for all Bash scripts. This ensures
the files are recognized as Bash scripts by the ShellCheck CI job, and
by editors/IDEs for improved syntax highlighting.
* ci - run storybook and add to build-artifacts
* ci/storybook - rename storybook build path and fix artifact upload
* ci/storybook - rename link text
* clean - remove accidently committed storybook build dir
* storybook - fix image path to relative (#10364)
* use @lavamoat/allow-scripts for package postinstall allow list
* dnode: set "weak" to false
Co-authored-by: kumavis <kumavis@users.noreply.github.com>
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
Dependencies are now cached between builds, using a checksum of the
`yarn.lock` file as the cache key. The `node_modules` directory and the
`.har` file from the install are cached and restored, so that we ensure
the record of the install is always preserved alongside the
dependencies.
The consolidation of the `collect-har-artifact` script was to make it
easier to cache the `.har` file along with the dependencies.
We don't look at coveralls very much. We might occasionally consult it
to see a report on our code coverage, but that report is already
generated entirely locally, and has been added to the MetaMask bot
comment in #10061.
The CI config has been updated to use CircleCI executors. This allows
us to define the container environments used in one place, and reuse
these environment definitions between jobs.
This should result in no functional changes.
The Firefox e2e tests now use the `.zip` file for testing the
extension. We've found this to produce more similar results to
production, compared to the old method of loading the unzipped
directory.
Passing in a `.zip` file to the Chrome driver didn't seem to work. I
didn't investigate this further to see if it was possible, but I'm not
sure it makes a difference on Chrome anyway.
An e2e test has been added that uses the new mock Segment server to
verify that the three initial page metric events are sent correctly.
Using the mock Segment server requires a special build with this mock
Segment server hostname embedded, so a distinct job for building and
running this test was required. As such, it was left out of the
`run-all.sh` script.
The sesify viz step of the build was broken in #9838 when
`eth-rpc-errors@4` was introduced to the project. `eth-rpc-errors@4`
uses inline sourcemaps without including the full source in the
sourcemap, which breaks `sesify`.
`sesify` has been fixed[1] (under its new name, `lavamoat-browserify`),
but it has been disabled temporarily until this fix is included in a
new release, and until we can update to use it.
[1]: https://github.com/LavaMoat/LavaMoat/pull/121
This reduces the footprint of each Node process in an attempt to try
and lower the failure rate.
> Expected behavior with –max-old-space-size within container constraints
>
> By default, Node.js (up to 11.x) uses a maximum heap size of 700MB and 1400MB
> on 32-bit and 64-bit platforms, respectively. For current defaults, see the
> reference mentioned at the end of blog.
[1]:https://developer.ibm.com/languages/node-js/articles/nodejs-memory-management-in-container-environments/
The remaining integration tests are all covered by e2e tests, so
they're no longer needed.
All associated scripts, fixtures, and dependencies have also been
removed.
The version bump script referenced the old file path for the manifest.
It was stored as a single file called `manifest.json`, but it was split
into `_base.json` and platform-specific manifests in #8140.
The manifest version bump script has been updated to reference
`_base.json`, which is the piece that has the version property.
Our JSDoc documentation has not been updated in a very long time, and
we don't use JSDoc in enough places for the docs to have been
especially useful. The tools and scripts used to generate and publish
these docs have been removed.
References to this documentation have also been removed from the
README.
Hopefully once the TypeScript migration has made substantial progress,
we can generate more useful documentation using something like TypeDoc.
The Storybook deploy step is currently broken because it's using the
wrong source branch (`master` instead of `develop`), and because the
key that CircleCI is setup with doesn't have write access to the repo.
While I expect we'll get these two problems fixed soon, this ensures
that we at least have passing builds on `develop` in the meantime.
* Minimum changes to get storybook working
Undo path changes
* Add build:storybook scripts to package.json
* Add storybook deployer
* Add storybook:deploy to package.json
* Update circle ci config
* Update yarn.lock
* Remove addon-info
* Update yarn.lock file to reflect removing of addon-info
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
* Add benchmark to CI
The page load benchmark for Chrome is now run during CI, and the
results are collected and summarized in the `metamaskbot` comment.
Closes#6881
* Double default number of samples
The number of default samples was changed from 10 to 20. The results
from 10 samples would show statistically significant changes in page
load times between builds, so weren't a sufficiently useful metric.
This reverts commit 4b4c00e94f. The
original change was a possible optimization of CI, though it ended up
not having a huge impact. It was thought that it may have broken source
maps, because the test build overwrote the `dist` directory that the
source maps were written to. However this turned out not to be the
case, as the changes to `dist` are never persisted to the workspace.
This is being re-introduced because the test build is needed for an
additional job (the page load benchmark), and sharing the same build
for all three jobs would surely be faster than building it separately
three times.
* Add shellcheck lint script
* Add to build
* Add shellcheck lint to main lint task
* Put shellcheck in the right place, hopefully?
* Fix declared multiple executor types
* Add sudo
* Address shellcheck warnings
* Add test-lint-shellcheck
* Add test-lint-shellcheck to workflow
* Use correct lint task
* output version which could be helpful for debugging
* Address PR feedback
* consistency++
