This results in faster completions on Azure Pipelines. For an individual
build (OS/Node.js combination) it shaves off ~10 or more minutes, depending on
the OS.
Once the `lint` and `test` steps have collective implementations we should be
able to shave another couple of minutes off of the completion times.
The steps that take the longest are `yarn install` (~4 minutes), collective
`typecheck` (~4 minutes), and `ci:dapps` (~3 minutes).
Make various related changes to templates, tests, etc. The methodology for
finding files that needed changes was to search through the whole monorepo for
the strings "solc" and "solidity" and then inspect the hits to see whether
changes were needed/appropriate.
Remove `solc` as a dependency in `packages/embark/package.json` so that it's
only a proper dependency in `packages/plugins/solidity/package.json`. Adjust
how the "bundled" `solc` package's version is determined, i.e. inspect the
`package.json` of `embark-solidity` instead of `embark`.
When `solc`'s version is `>=0.6.0` use the [new callback API][api].
[api]: https://github.com/ethereum/solc-js/blob/master/README.md#example-usage-with-import-callback
Changes the way the logs are stored to straight up be logged as an
array and then reads it as such. It also removes the reverse from
the read and puts it in the UI instead since it's the UI that needs
it reversed.
## User reported error
i recently updated to embark 5.0 im having issues connecting to a local node each time i connect to it i get the following output from the embark console
```
Error during proxy setup: Port should be >= 0 and < 65536. Received 754510.. Use '--loglevel debug' for more detailed information.
```
This is what i have under the blockchain.js file
```
localDev: {
endpoint: "http://127.0.0.1:7545",
accounts: [{
nodeAccounts: true,
}]
}
```
### Problem
The port to start the proxy on is incremented by a constant value (using the `+` operator), however the port comes from the config and in the case where it is a string, the `+` operator acts as a string concatentation.
### Fix
Ensure the port from the config is always parsed to a number before attempting to add the constant proxy port offset.
Also, in `dapps/tests/contracts` move the `this.timeout(0);` inside the
`it(...)` for the expensive gas esimation (involving
`SimpleStorage.methods.set`) because it otherwise doesn't seem to have an
effect on the default 15 second timeout.
When we introduced dappConnection to ENS, we didn't add the concept
of auto connection, like we do in the "normal" connection. This
means that when using $WEB3, the contracts connection waited for
the user to click on a button, but the ENS part called `ethereum.enable`
directly, which is confusing for the dev, because we specified to
NOT automatically connect to ethreum.
This fixes it by checking the dappAutoEnable property in contracts
config and adds it to the namesystemConfig artifact
And remove `suggestions.json` in the `"files"` list of
`packages/core/console/package.json` since it was moved to
`packages/plugins/suggestions/suggestions.json`.
Remove the `<12.0.0` restriction re: Node.js version in the `"engines"`
settings for all the packages in the monorepo that had that restriction.
Add missing `"engines"` settings in `packages/plugins/snark/package.json`.
Adjust the Azure Pipelines config to include builds for Node.js v12.x and
v13.x.
Bump `solc` to `0.4.26` in `dapps/tests/app` and `dapps/tests/contracts`. It
was discovered that older versions suffered a fatal `Maximum call stack size
exceeded` error when run on Windows with Node.js v12.x or newer. Display a
warning re: the bad combo (solc version + Windows + Node version) if it's
detected at runtime.
Adjust the root `yarn.lock` so that the `sha3` transitive dependency resolves
to a newer version that is compatible with Node v13.x.
Whenever a PR is opened and commits are force-/pushed to the corresponding
branch, up to present the behavior has been that two sets of Azure Pipelines
builds are run: one is caused by the default PR trigger and the other is caused
by the default commits trigger. With the changes in this commit, the goal is to
retain the behavior of builds running for every commit to any branch (including
PR branches) but to disable the PR trigger. That will be helpful when our Azure
Pipelines cofig is soon updated with a build matrix that includes Node v12.x
and v13.x, i.e. instead of 18 builds any time a PR is opened or updated there
will be 9.
This change may not achieve the desired outcome; if it does not then it will be
undone.
Implement a GitHub Actions workflow in `.github/workflows/nightlies.yml` named
*Nightlies*, which is scheduled to run once daily at 00:00 UTC.
At present the workflow includes one job named *release*, which is responsible
for publishing prerelease GitHub releases and NPM packages. Each prerelease
created (per package) will have a `nightly` [semver identifier][preid], and
each successive nightly release will be paired with the `nightly`
[dist-tag][dist-tag] on the NPM registry (per package).
During the release job, actions taken in this GitHub repository (commits, tags,
releases) and on the NPM registry (package publication) will be performed using
credentials associated with the following accounts:
* https://github.com/embarkbot
* https://www.npmjs.com/~embarkbot
For that purpose, corresponding [secrets][secrets] (link requires admin access)
were created in this repository consisting of API tokens generated for the
@embarkbot GitHub and NPM accounts. Logins for the @embarkbot accounts
themselves are protected by 2FA.
Implement `scripts/nightly-release.js` (`npm run release:nightly`), which is
responsible for running `lerna publish` in the GitHub Actions workflow. Also
implement `scripts/stable-release.js` (`npm run release:stable`), which is
intended to be run locally by someone on the Embark Team. Both scripts borrow
heavily from the existing `scripts/release.js`, and the process of authoring
and experimenting with them influenced refactors to the latter.
Use a `--force-publish` major-release strategy to prevent major-version drift
between packages in the monorepo. How it works: when the stable-release script
is run (`npm run release:stable`), if the current prerelease version involves a
major version increase relative to the most recent stable release then **all**
packages are bumped to the new major stable version. Otherwise, only the
packages currently in prerelease are graduated to the new minor/patch stable
version. In either case, the `nightly` dist-tag of each package published is
updated to resolve to the new stable version.
The reason for adopting this strategy *(a decision which can be revisited and
changed any time in the future)* is based on a concern that downstream users
would have a confusing developer UX if across `embark-*` packages there are
differing major versions.
To understand how the major-version drift would happen, consider the following
hypothetical scenario where `--force-publish` *isn't* used in stable releases
and `nightly` dist-tags aren't updated to resolve to the latest stable version:
assume the current stable version is `6.5.4`. A breaking change lands for
`embark-core`. The next nightly release bumps `embark-core` and about 40 other
packages to `7.0.0-nightly.0`. However, `embark-utils` (and others) isn't
bumped because it doesn't depend on `embark-core`. Later, without any
intervening changes to `embark-utils`, the prerelease is graduated so that
`embark-core`, etc. bump to `7.0.0`. So then some `embark-*` packages are at
major version `7` while others are still at `6`. *Note* that this is the case
even though this monorepo uses Lerna's *"fixed"* versioning mode. Inside the
monorepo, `lerna` makes sure that everything is okay, i.e. with respect to
automatically updating dependents' version specifiers for their dependencies
that are within the monorepo. But for downstream users things are a bit more
complex. If someone wanted to use `embark-utils` on its own and specified
`^7.0.0` as the version range (after observing that `embark` itself is in a
`7.x` series) it won't work because `embark-utils` is still in `6.x`. In the
general case, users may have to manually cross-check major versions of various
`embark-*` packages that they specify in their projects' `package.json`
files. There are tools like [npm-check-updates][ncu] that can make the task
easier, but there is still likely to be some confusion, especially given the
large and growing number of packages in this monorepo. Another area of
confusion would exist around the `nightly` dist-tag. In the scenario above,
`embark-core@nightly` (and/or `@nightly` of its dependents, e.g. `embark`)
would resolve to `7.0.0-nightly.0` but `embark-utils@nightly` would resolve to
some `6.5.4-nightly.N` (💣), i.e. a prerelease version that predates the
current stable `6.5.4` release of `embark-utils` (and *might* not include all
changes that landed in `embark-utils` prior to that stable release).
By bumping all packages each time there is a major stable release, and by
having the `nightly` dist-tag always point to a package's most recent
release (whether stable or prerelease), the problems described above are
avoided.
To see the `--force-publish` major-release strategy in action take a look at
the [commit history][history] for the
[nightly-release-workflow-tester][mb-nrwt] repo together with the *Versions*
tab of the NPM pages for the [foo][foo], [bar][bar], [baz][baz], and
[quux][quux] packages. Ignore the version history for `<= 2.0.1` because those
pre/releases were made with a different strategy than the current one.
Refactor the existing `scripts/release.js` to make it more flexible generally
and with respect to options that can be forwarded to `lerna`. In particular,
it's now possible to run `lerna version` instead of `lerna publish` (the
default behavior) by using the `--version-only` cli option; when combining that
usage with `--skip-qa` and `--no-push` it's possible to conveniently and
quickly experiment with the [`bump` positional][bump] and additional options
such as `--force-publish`, `--conventional-prerelease`, and
`--conventional-graduate`, i.e. to better understand how `lerna` will update
package versions. That ability should make it much simpler to figure out the
best course of action to take locally (manually) when a nightly release
completely or partially failed (which could happen for a number of reasons), as
well for other scenarios such as making a minor/patch release in a previous
line of major releases, or when making two/more successive stable releases
without a nightly release having happened in the meantime.
An important change to `scripts/release.js` is that by default it makes use of
the `--create-release github` option for `lerna version|publish`. For that to
work, an environment variable named `GH_TOKEN` must be defined with a properly
[scoped][scopes] GitHub [personal access token][pa-token] (`public_repo` scope
is sufficient for creating releases). The same is true for
`scripts/stable-release.js`.
Delete the `.github/PULL_REQUEST_TEMPLATE` directory and the templates it
contained. Unlike for GitHub issue creation, there is no prompt-page for
picking from a repo's PR templates; to use a PR template a `template=[name]`
[query parameter][template-query] must be appended to the URL of the PR
creation page. So the PR templates ended up unused by the Embark Team and
external contributors because it's not convenient to use them. Restore the
default PR template we had in place some time ago (with some small revisions)
since it seems like a helpful starting point, especially for external
contributors. Consistently use all-lowercase filenames for ISSUE/PR templates.
[preid]: https://semver.org/#spec-item-9
[dist-tag]: https://docs.npmjs.com/cli/dist-tag
[secrets]: https://github.com/embarklabs/embark/settings/secrets
[ncu]: https://www.npmjs.com/package/npm-check-updates
[history]: https://github.com/michaelsbradleyjr/nightly-release-workflow-tester/commits/master
[mb-nrwt]: https://github.com/michaelsbradleyjr/nightly-release-workflow-tester/
[foo]: https://www.npmjs.com/package/nightly-release-workflow-tester-foo?activeTab=versions
[bar]: https://www.npmjs.com/package/nightly-release-workflow-tester-bar?activeTab=versions
[baz]: https://www.npmjs.com/package/nightly-release-workflow-tester-baz?activeTab=versions
[quux]: https://www.npmjs.com/package/nightly-release-workflow-tester-quux?activeTab=versions
[bump]: https://github.com/lerna/lerna/tree/master/commands/version#semver-bump
[scopes]: https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
[pa-token]: https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line
[template-query]: https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository
Fixes the use of Infura to connect to the ENS contracts. When
connecting directly to Infura, it would throw with `rejected due to
project ID settings`, because it doesn't accept the VM as the domain
Instead, when passing from the proxy, it works. So I changed the
default when no dappConnection to ['$EMBARK']. I also added a
message when the error happens to help users fix it themselves
When in the testnet, we don,t register because we already have the
addresses, which is fine, but we also didn't populate the ensConfig
object which contains the important information about the addresses
and ABI.
There was a lot of lint problems in a couple of files so I cleaned
that up
## Problem
Doing read, then write each a trasaction or call exectues could get
heavy, especially with regular txs on
This was especially true in the tests, which led to deactivate the
tx logger in the tests
## Solution
Instead of reading the whole file, adding the JSON line a writing,
we instead just append some pseudo JSON to it that later gets read
and parsed correctly back to JSON
Michael Bradley, Jr
EmbarkBot
dependabot-preview[bot]
Jinho Jang
Jonathan Rainville
Marc
Pascal Precht
emizzle
Iuri Matias