This repository is deprecated. Integration tests are now in the polymesh-dev-env project
Here is a collection of integration tests to help ensure the various Polymesh services work together correctly.
The tests primarily make use of the REST API, which in turn imports the SDK.
By default yarn test will use docker compose up to setup a docker environment with the latest docker image for each service. Look in envs/ for supported image sets. Look in scripts/setup.sh to see the set of images under test.
The URLs of the services under test can be set with environment variables. Look at the environment.ts file for a complete list
To test a local image update the corresponding env to be set to the local tag name. docker compose by default attempts to pull, so you will need to add pull_policy: never to the respective service.
yarn build:tscompiles typescript files into javascript and type declarations. Outputs todist/directoryyarn build:docsbuilds a documentation page from tsdoc comments in the code. Outputs todocs/directoryyarn testruns tests and outputs the coverage reportyarn commitruns the commit formatting tool (should replace normal commits)yarn semantic-releaseruns semantic release to calculate version numbers based on the nature of changes since the last version (used in CI pipelines)yarn lintruns the linter on all .ts(x) and .js(x) files and outputs all errorsyarn formatruns prettier on all .ts(x) and .js(x) files and formats them according to the project standards
- All tools are configured via their respective config files instead of adding the config in
package.json. There is also some vscode project config in.vscode/settings.json- eslint:
.eslintrc - lint-staged:
.lintstagedrc - prettier:
.prettierrc - commitlint:
commitlint.config.js - husky:
.husky - jest:
jest.config.js - semantic-release:
release.config.js - typedoc:
typedoc.json - github actions:
.github/main.yml
- eslint:
- The CI config assumes a
masterbranch for stable releases and abetabranch for beta releases. Every time something gets pushed to either of those branches (or any time a pull request is opened to any branch), github actions will run. Semantic-release config makes it so that actual releases are only made on pushes tomasterorbeta - The CI config also adds an extra couple of steps to flatten the file structure that actually gets published. This means that your published package will have the buit files at the root level instead of inside a
distfolder. Those steps are:- copy
package.jsoninto thedistfolder after building cdinto thedistfolder- install deps into the
distfolder - run
semantic-releasefrom there
- copy
- In order for automated NPM releases to actually work, you need to add an NPM auth token as a secret in your repo. To do that, go to your repo's
settings -> secrets -> add a new secretinputNPM_TOKENas the secret name and the token you generated on your NPM account in the text area - If you don't need automated NPM releases, you might want to uninstall
semantic-releaseand tweak the github actions yaml file to skip the release step