mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-06-13 00:01:09 +00:00
Markdown linter (#1309)
* Add markdown linting - add linter default rules - adapt rules to current code - fix the code for linting to pass - add CI check fix #1243 * Fix markdown for Substrate * Fix tooling install * Fix workflow * Add documentation * Remove trailing spaces * Update .github/.markdownlint.yaml Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Fix mangled markdown/lists * Fix captalization issues on known words
This commit is contained in:
+18
-12
@@ -1,19 +1,22 @@
|
||||
## Using Containers
|
||||
# Using Containers
|
||||
|
||||
Using containers via **Podman** or **Docker** brings benefit, whether it is to build a container image or
|
||||
run a node while keeping a minimum footprint on your local system.
|
||||
Using containers via **Podman** or **Docker** brings benefit, whether it is to build a container image or run a node
|
||||
while keeping a minimum footprint on your local system.
|
||||
|
||||
This document mentions using `podman` or `docker`. Those are usually interchangeable and it is encouraged using preferably **Podman**. If you have podman installed and want to use all the commands mentioned below, you can simply create an alias with `alias docker=podman`.
|
||||
This document mentions using `podman` or `docker`. Those are usually interchangeable and it is encouraged using
|
||||
preferably **Podman**. If you have podman installed and want to use all the commands mentioned below, you can simply
|
||||
create an alias with `alias docker=podman`.
|
||||
|
||||
There are a few options to build a node within a container and inject a binary inside an image.
|
||||
|
||||
### Parity built container image
|
||||
## Parity built container image
|
||||
|
||||
Parity builds and publishes a container image that can be found as `docker.io/parity/polkadot-parachain`.
|
||||
|
||||
### Parity CI image
|
||||
## Parity CI image
|
||||
|
||||
Parity maintains and uses internally a generic "CI" image that can be used as a base to build binaries: [Parity CI container image](https://github.com/paritytech/scripts/tree/master/dockerfiles/ci-linux):
|
||||
Parity maintains and uses internally a generic "CI" image that can be used as a base to build binaries: [Parity CI
|
||||
container image](https://github.com/paritytech/scripts/tree/master/dockerfiles/ci-linux):
|
||||
|
||||
The command below allows building a Linux binary without having to even install Rust or any dependency locally:
|
||||
|
||||
@@ -29,19 +32,22 @@ sudo chown -R $(id -u):$(id -g) target/
|
||||
If you want to reproduce other steps of CI process you can use the following
|
||||
[guide](https://github.com/paritytech/scripts#gitlab-ci-for-building-docker-images).
|
||||
|
||||
### Injected image
|
||||
## Injected image
|
||||
|
||||
Injecting a binary inside a base image is the quickest option to get a working container image. This only works if you were able to build a Linux binary, either locally, or using a container as described above.
|
||||
Injecting a binary inside a base image is the quickest option to get a working container image. This only works if you
|
||||
were able to build a Linux binary, either locally, or using a container as described above.
|
||||
|
||||
After building a Linux binary ()`polkadot-parachain`) with cargo or with Parity CI image as documented above, the following command allows producing a new container image where the compiled binary is injected:
|
||||
After building a Linux binary ()`polkadot-parachain`) with cargo or with Parity CI image as documented above, the
|
||||
following command allows producing a new container image where the compiled binary is injected:
|
||||
|
||||
```bash
|
||||
./docker/scripts/build-injected-image.sh
|
||||
```
|
||||
|
||||
### Container build
|
||||
## Container build
|
||||
|
||||
Alternatively, you can build an image with a builder pattern. This options takes a while but offers a simple method for anyone to get a working container image without requiring any of the Rust toolchain installed locally.
|
||||
Alternatively, you can build an image with a builder pattern. This options takes a while but offers a simple method for
|
||||
anyone to get a working container image without requiring any of the Rust toolchain installed locally.
|
||||
|
||||
```bash
|
||||
docker build \
|
||||
|
||||
+30
-25
@@ -37,8 +37,8 @@ performed during the release process.
|
||||
|
||||
### <a name="burnin"></a>Burn In
|
||||
|
||||
Ensure that Parity DevOps has run the new release on Westend and Kusama Asset Hub collators for 12h
|
||||
prior to publishing the release.
|
||||
Ensure that Parity DevOps has run the new release on Westend and Kusama Asset Hub collators for 12h prior to publishing
|
||||
the release.
|
||||
|
||||
### Build Artifacts
|
||||
|
||||
@@ -75,56 +75,61 @@ function of the appropriate pallets.
|
||||
|
||||
### Extrinsic Ordering & Storage
|
||||
|
||||
Offline signing libraries depend on a consistent ordering of call indices and
|
||||
functions. Compare the metadata of the current and new runtimes and ensure that
|
||||
the `module index, call index` tuples map to the same set of functions. It also checks if there have been any changes in `storage`. In case of a breaking change, increase `transaction_version`.
|
||||
Offline signing libraries depend on a consistent ordering of call indices and functions. Compare the metadata of the
|
||||
current and new runtimes and ensure that the `module index, call index` tuples map to the same set of functions. It also
|
||||
checks if there have been any changes in `storage`. In case of a breaking change, increase `transaction_version`.
|
||||
|
||||
To verify the order has not changed, manually start the following [Github Action](https://github.com/paritytech/cumulus/actions/workflows/extrinsic-ordering-check-from-bin.yml). It takes around a minute to run and will produce the report as artifact you need to manually check.
|
||||
To verify the order has not changed, manually start the following [Github
|
||||
Action](https://github.com/paritytech/cumulus/actions/workflows/extrinsic-ordering-check-from-bin.yml). It takes around
|
||||
a minute to run and will produce the report as artifact you need to manually check.
|
||||
|
||||
To run it, in the _Run Workflow_ dropdown:
|
||||
1. **Use workflow from**: to ignore, leave `master` as default
|
||||
2. **The WebSocket url of the reference node**:
|
||||
- Asset Hub Polkadot: `wss://statemint-rpc.polkadot.io`
|
||||
2. **The WebSocket url of the reference node**: - Asset Hub Polkadot: `wss://statemint-rpc.polkadot.io`
|
||||
- Asset Hub Kusama: `wss://statemine-rpc.polkadot.io`
|
||||
- Asset Hub Westend: `wss://westmint-rpc.polkadot.io`
|
||||
3. **A url to a Linux binary for the node containing the runtime to test**: Paste the URL of the latest release-candidate binary from the draft-release on Github. The binary has to previously be uploaded to S3 (Github url link to the binary is constantly changing)
|
||||
3. **A url to a Linux binary for the node containing the runtime to test**: Paste the URL of the latest
|
||||
release-candidate binary from the draft-release on Github. The binary has to previously be uploaded to S3 (Github url
|
||||
link to the binary is constantly changing)
|
||||
- E.g: https://releases.parity.io/cumulus/v0.9.270-rc3/polkadot-parachain
|
||||
4. **The name of the chain under test. Usually, you would pass a local chain**:
|
||||
- Asset Hub Polkadot: `asset-hub-polkadot-local`
|
||||
4. **The name of the chain under test. Usually, you would pass a local chain**: - Asset Hub Polkadot:
|
||||
`asset-hub-polkadot-local`
|
||||
- Asset Hub Kusama: `asset-hub-kusama-local`
|
||||
- Asset Hub Westend: `asset-hub-westend-local`
|
||||
5. Click **Run workflow**
|
||||
|
||||
When the workflow is done, click on it and download the zip artifact, inside you'll find an `output.txt` file. The things to look for in the output are lines like:
|
||||
When the workflow is done, click on it and download the zip artifact, inside you'll find an `output.txt` file. The
|
||||
things to look for in the output are lines like:
|
||||
|
||||
- `[Identity] idx 28 -> 25 (calls 15)` - indicates the index for Identity has changed
|
||||
- `[+] Society, Recovery` - indicates the new version includes 2 additional modules/pallets.
|
||||
- If no indices have changed, every modules line should look something like `[Identity] idx 25 (calls 15)`
|
||||
|
||||
**Note**: Adding new functions to the runtime does not constitute a breaking change
|
||||
as long as the indexes did not change.
|
||||
**Note**: Adding new functions to the runtime does not constitute a breaking change as long as the indexes did not
|
||||
change.
|
||||
|
||||
**Note**: Extrinsic function signatures changes (adding/removing & ordering arguments) are not caught by the job, so those changes should be reviewed "manually"
|
||||
**Note**: Extrinsic function signatures changes (adding/removing & ordering arguments) are not caught by the job, so
|
||||
those changes should be reviewed "manually"
|
||||
|
||||
### Benchmarks
|
||||
|
||||
The Benchmarks can now be started from the CI. First find the CI pipeline from [here](https://gitlab.parity.io/parity/mirrors/cumulus/-/pipelines?page=1&scope=all&ref=release-parachains-v9220) and pick the latest.
|
||||
[Guide](https://github.com/paritytech/ci_cd/wiki/Benchmarks:-cumulus)
|
||||
The Benchmarks can now be started from the CI. First find the CI pipeline from
|
||||
[here](https://gitlab.parity.io/parity/mirrors/cumulus/-/pipelines?page=1&scope=all&ref=release-parachains-v9220) and
|
||||
pick the latest. [Guide](https://github.com/paritytech/ci_cd/wiki/Benchmarks:-cumulus)
|
||||
|
||||
### Integration Tests
|
||||
|
||||
Until https://github.com/paritytech/ci_cd/issues/499 is done, tests will have to be run manually.
|
||||
1. Go to https://github.com/paritytech/parachains-integration-tests and check out the release branch.
|
||||
E.g. https://github.com/paritytech/parachains-integration-tests/tree/release-v9270-v0.9.27
|
||||
for `release-parachains-v0.9.270`
|
||||
1. Go to https://github.com/paritytech/parachains-integration-tests and check out the release branch. E.g.
|
||||
https://github.com/paritytech/parachains-integration-tests/tree/release-v9270-v0.9.27 for `release-parachains-v0.9.270`
|
||||
2. Clone `release-parachains-<version>` branch from Cumulus
|
||||
3. `cargo build --release`
|
||||
4. Copy `./target/polkadot-parachain` to `./bin`
|
||||
5. Clone `it/release-<version>-fast-sudo` from Polkadot
|
||||
In case the branch does not exists (it is a manual process): cherry pick paritytech/polkadot@791c8b8 and run
|
||||
`find . -type f -name "*.toml" -print0 | xargs -0 sed -i '' -e 's/polkadot-vX.X.X/polkadot-v<version>/g'`
|
||||
5. Clone `it/release-<version>-fast-sudo` from Polkadot In case the branch does not exists (it is a manual process):
|
||||
cherry pick `paritytech/polkadot@791c8b8` and run:
|
||||
`find . -type f -name "*.toml" -print0 | xargs -0 sed -i '' -e 's/polkadot-vX.X.X/polkadot-v<version>/g'`
|
||||
6. `cargo build --release --features fast-runtime`
|
||||
7. Copy `./target/polkadot` into `./bin` (in Cumulus)
|
||||
8. Run the tests:
|
||||
- Asset Hub Polkadot: `yarn zombienet-test -c ./examples/statemint/config.toml -t ./examples/statemint`
|
||||
- Asset Hub Kusama: `yarn zombienet-test -c ./examples/statemine/config.toml -t ./examples/statemine`
|
||||
- Asset Hub Polkadot: `yarn zombienet-test -c ./examples/statemint/config.toml -t ./examples/statemint`
|
||||
- Asset Hub Kusama: `yarn zombienet-test -c ./examples/statemine/config.toml -t ./examples/statemine`
|
||||
|
||||
Reference in New Issue
Block a user