The `auto-changelog.js` script crashes when trying to add a new release
header. This bug was introduced in #10847. The cause was a simple
misnamed parameter.
* Add jest coverage
This will add coverage for any tests ran in jest under the `test:coverage:jest` command, which is currently being used in CI. I set the values to the current test coverage in `ui/app/pages/swaps`.
* Lint
* Setup jest config
* Adjust test for jest.
* Adjust lint config
* Omit swaps ui folder for unit testing
* Omit swaps from test:unit:lax
* Add jest.config.js to script files
* Restore mocks rather than clearing them.
* Update jest config and adjust lint to include subdirs
* Convert view-quote-price-difference test to jest
* Add jest ci and ci coverage scripts. Add jest unit test to general test command
* Add test coverage to ci
* Use --ignore flag
* Fixup
* Add @metamask/eslint-config-jest
* Update .eslintrc.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Adds jest-coverage/
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
When updating the changelog for a release candidate, any unreleased
changes are now migrated to the release header.
Generally we don't make a habit of adding changes to the changelog
prior to creating a release candidate, but if any are there we
certainly don't want them duplicated.
* Increase default slippage from 2% to 3%, show Advanced Options by default
* Disable opening / closing of Advanced Options on the Swap page
* Pre-select previously used slippage value when going back to the Swap page
* Fix lint issues
* Use a callback for setting up an initial customValue
The `auto-changelog.js` script has been refactoring into various
different modules. This was done in preparation for migrating this to
a separate repository, where it can be used in our libraries as well.
Functionally this should act _mostly_ the same way, but there have been
some changes. It was difficult to make this a pure refactor because of
the strategy used to validate the changelog and ensure each addition
remained valid. Instead of being updated in-place, the changelog is now
parsed upfront and stored as a "Changelog" instance, which is a new
class that was written to allow only valid changes. The new changelog
is then stringified and completely overwrites the old one.
The parsing had to be much more strict, as any unanticipated content
would otherwise be erased unintentionally. This script now also
normalizes the formatting of the changelog (though the individual
change descriptions are still unformatted).
The changelog stringification now accommodates non-linear releases as
well. For example, you can now release v1.0.1 *after* v2.0.0, and it
will be listed in chronological order while also correctly constructing
the `compare` URLs for each release.
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.
Each changelog release now has category headers. The standard "keep a
changelog" [1] categories are used, along with the addition of
"Uncategorized" for any changes that have not yet been categorized.
The changelog script has been updated to add this "Uncategorized"
header if it isn't already present, and to place any new commits under
this header.
The changelog has been updated to property categorize each change in
recent releases, and to place changes in older releases under the
header "Uncategorized".
[1]: https://keepachangelog.com/en/1.0.0/
* origin/develop: (82 commits)
Add links to release headers (#10808)
Removing unnecessary params from withFixtures function call. (#10831)
Fix _getPermittedAccounts type safety (#10819)
Refactoring send-edit.spec.js to use fixtures (#10792)
Refactoring address-book.spec.js to use fixtures (#10804)
Update the changelog when creating an RC (#10795)
Update changelog headers and fix dates (#10805)
Add support for locators into driver abstraction (#10802)
remove node-sass dependency (#10797)
Add release header when updating changelog (#10794)
Ensure correct primary currency image is displayed on home screen and token list (#10777)
upgrade eslint deps (#10789)
only applies rules to the appropriate files (#10788)
Set the BSC_CONTRACT_ADDRESS to lowercase (#10800)
Prevent duplicate changelog entries (#10786)
Add changelog entries under release candidate header (#10784)
Remove script for creating master sync PR (#10791)
Remove date from changelog release header (#10790)
Remove useless negation (#10787)
Refactoring ethereum-on.spec.js to use fixtures (#10778)
...
Each release header now includes a link to the range of commits
included with that release. These links are at the end of the document,
in accordance with the "keep a changelog" [1] format.
For the purpose of this changelog, the "previous release" is the most
recent release mentioned in the changelogs. The diffs ignore any
releases that were omitted from the changelog. This is mainly an issue
with older releases, so it seemed acceptable. All releases have been
documented for a couple of years now, and will be going forward as
well.
The name of the "Current Develop Branch" section was changed to
"Unreleased" to confirm with "keep a changelog".
The `auto-changelog.js` script has been updated to update/add these
links whenever adding a new release header as well.
[1]: https://keepachangelog.com/en/1.0.0/
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 changelog release header format has been updated to match the "keep
a changelog" [1] format. Each header is now the bracketed version
number followed by a dash, then the release date in ISO-8601 format.
The release dates in each header were also updated to match the date of
the corresponding GitHub Release [2]. Many of these dates were
incorrect because they were set on the day we created the release
candidate, rather than on the day of release.
Any changelog release entries without a corresponding GitHub release
was left with the date already specified.
The three oldest release headers were missing dates. For the first two,
I used the date of the version bump commit. For the third, I removed it
since no changes were listed anyway, and it represented a range of
releases rather than a single one.
The `auto-changelog.js` script has been updated to account for this new
format as well.
[1]: https://keepachangelog.com/en/1.0.0/
[2]: https://github.com/MetaMask/metamask-extension/releases
* Replace logic for eth swap token in fetchQuotesAndSetQuoteState with getSwapsEthToken call (#10624)
* Move swaps constants to the shared constants directory (#10614)
* Fix: ETH 'token' now only appears once in the swaps to and from dropdowns. (#10650)
* Swaps support for local testnet (#10658)
* Swaps support for local testnet
* Create util method for comparison of token addresses/symbols to default swaps token
* Get chainId from txMeta in _trackSwapsMetrics of transaction controller
* Add comment to document purpose of getTransactionGroupRecipientAddressFilter
* Use isSwapsDefaultTokenSymbol in place of repeated defaultTokenSymbol comparisons in build-quote.js
* Additional swaps network support (#10721)
* Add swaps support for bnc chain
* Use single default token address in shared/constants/swaps
* Ensure swaps gas prices are fetched from the correct chain specific endpoint (#10744)
* Ensure swaps gas prices are fetched from the correct chain specific endpoint
* Just rely on fetchWithCache to cache swaps gas prices, instead of directly using storage in getSwapsPriceEstimatesLastRetrieved
* Empty commit
* update @metamask/etherscan-link to v2.0.0 (#10747)
* Use correct block explorer name and link in swaps when on custom network (#10743)
* Use correct block explorer name and link in swaps when on custom network.
* Fix up custom etherscan link code in build-quote.js
* Use blockExplorerUrl hostname instead of 'blockExplorerBaseUrl'
* Use correct etherscan-link method for token links in build-quote
* Create correct token link in build-quote for mainnet AND custom networks
* Block explorer url improvements in awaiting-swap.js and build-quote.js
* Use swapVerifyTokenExplanation message with substitutable block explorer for all applicable locales
* Ensure that block explorer links are not shown in awaiting-swap if no url is available
* Ensure that the correct default currency symbols are used for fees on the view quote screen (#10753)
* Updating y18n and netmask to resolve dependency issues (#10765)
netmask@1.0.6 -> 2.0.1, y18n@3.2.1 -> 3.2.2, y18n@4.0.0 -> 4.0.1
* Ensure that priceSlippage fiat amounts are always shown in view-quote.js (#10762)
* Ensure that the approval fee in the swaps custom gas modal is in network specific currency (#10763)
* Use network specific swaps contract address when checking swap contract token approval (#10774)
* Set the BSC_CONTRACT_ADDRESS to lowercase (#10800)
* Ensure correct primary currency image is displayed on home screen and token list (#10777)
* [skip e2e] Update changelog for v9.3.0 (#10740)
* Version v9.3.0
* [skip e2e] Update changelog for v9.3.0 (#10803)
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
Co-authored-by: ryanml <ryanlanese@gmail.com>
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
The changelog update script now prevents duplicate entries from being
added. Specifically, it will ensure that if a PR has been referenced
already in an entry, it will not add it again.
This should prevent it from adding duplicate entries for changes that
were cherry-picked into hotfix releases.
Note that this duplication prevention only works for entries containing
a PR number. We don't have any way to prevent duplicate entries yet in
cases where we don't know the associated PR. We will be preventing this
possibility entirely pretty soon in some upcoming release automation
changes though, so I'm not concerned about this omission.
Instead of always placing new changelog entries under the "Current
Develop Branch" header, the changelog script now places them under the
header for the current release if that release has not yet been tagged.
This eliminates one manual step from the release process.
Relates to #10752
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.
Our build script waits for the `close` event to determine whether the
task has exited. The `exit` event is a better representation of this,
because if a stream is shared between multiple processes, the process
may exit without the `close` event being emitted.
We aren't sharing streams between processes, so this edge case doesn't
apply to us. This just seemed like a more suitable event to listen to,
since we care about the process exiting not the stream ending.
See this description of the `close` event from the Node.js
documentation [1]:
>The `'close'` event is emitted when the stdio streams of a child
>process have been closed. This is distinct from the `'exit'` event,
>since multiple processes might share the same stdio streams.
And see this description of the `exit` event:
>The `'exit'` event is emitted after the child process ends.
[1]: https://nodejs.org/docs/latest-v14.x/api/child_process.html#child_process_event_exit
Daniel
Mark Stacey
Thomas Huang
Niranjana Binoy
Erik Marks
Brad Decker
David Walsh
MetaMask Bot
Dan J Miller
Muhammet Kara
kumavis