-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add tests for Peregrine #3
Conversation
@ggera Please check out a solution for Kubernetes instead of the Binary compilation as it takes too long. A docker based setup would be better. |
1 similar comment
@ggera Please check out a solution for Kubernetes instead of the Binary compilation as it takes too long. A docker based setup would be better. |
DIP consumers are specific to a given provider. Right now, the template provider uses `u32` as block numbers, while `Peregrine` uses `u64`. This means that it is not possible to use a single consumer runtime (hence Docker image) to test both providers. The issue is fixed by making the provider template use the same block number type as Peregrine, so we can "stretch" it to be used in integration tests against the template consumer without having to have two different consumer runtimes and Docker images. To keep it consistent (although it is not required), I also changed the consumer runtime to use `u64`s. Integration tests with the DIP-SDK are finally passing. You can run them yourself following the instructions below. ## Checklist - [x] Apply change - [x] Build and push temp Docker images - [x] Verify integration tests for same template consumer work with both template provider and Peregrine - [ ] Review PR ## How to test * Clone the [DIP-SDK repo at this branch for PR #3](KILTprotocol/dip-sdk#3) * Set the env variables in `tests/peregrine-dip-consumer-template/.env.develop.test` for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and in `tests/dip-provider-template-dip-consumer-template/.env.develop.test` for `PROVIDER_IMAGE` to `kiltprotocol/dip-provider-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc`. * Run `yarn test:e2e:start-network:peregrine-provider:develop` to spin up the Zombienet network for Peregrine <-> DIP consumer * In a different bash, run `yarn test:e2e:peregrine-provider` to run the integration tests * Same thing with `yarn test:e2e:start-network:dip-template-provider:develop` and `yarn test:e2e:dip-template-provider`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM minor comment
@@ -22,6 +22,3 @@ cjs | |||
# VSCode | |||
|
|||
.vscode | |||
|
|||
# Tests | |||
.env.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we getting rid of this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because I think it's better to have them in, as they will be used by the CI as well. It does not hurt.
ffb3e35
to
15da2b1
Compare
DIP consumers are specific to a given provider. Right now, the template provider uses `u32` as block numbers, while `Peregrine` uses `u64`. This means that it is not possible to use a single consumer runtime (hence Docker image) to test both providers. The issue is fixed by making the provider template use the same block number type as Peregrine, so we can "stretch" it to be used in integration tests against the template consumer without having to have two different consumer runtimes and Docker images. To keep it consistent (although it is not required), I also changed the consumer runtime to use `u64`s. Integration tests with the DIP-SDK are finally passing. You can run them yourself following the instructions below. ## Checklist - [x] Apply change - [x] Build and push temp Docker images - [x] Verify integration tests for same template consumer work with both template provider and Peregrine - [ ] Review PR ## How to test * Clone the [DIP-SDK repo at this branch for PR #3](KILTprotocol/dip-sdk#3) * Set the env variables in `tests/peregrine-dip-consumer-template/.env.develop.test` for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and in `tests/dip-provider-template-dip-consumer-template/.env.develop.test` for `PROVIDER_IMAGE` to `kiltprotocol/dip-provider-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc`. * Run `yarn test:e2e:start-network:peregrine-provider:develop` to spin up the Zombienet network for Peregrine <-> DIP consumer * In a different bash, run `yarn test:e2e:peregrine-provider` to run the integration tests * Same thing with `yarn test:e2e:start-network:dip-template-provider:develop` and `yarn test:e2e:dip-template-provider`.
DIP consumers are specific to a given provider. Right now, the template provider uses `u32` as block numbers, while `Peregrine` uses `u64`. This means that it is not possible to use a single consumer runtime (hence Docker image) to test both providers. The issue is fixed by making the provider template use the same block number type as Peregrine, so we can "stretch" it to be used in integration tests against the template consumer without having to have two different consumer runtimes and Docker images. To keep it consistent (although it is not required), I also changed the consumer runtime to use `u64`s. Integration tests with the DIP-SDK are finally passing. You can run them yourself following the instructions below. ## Checklist - [x] Apply change - [x] Build and push temp Docker images - [x] Verify integration tests for same template consumer work with both template provider and Peregrine - [ ] Review PR ## How to test * Clone the [DIP-SDK repo at this branch for PR #3](KILTprotocol/dip-sdk#3) * Set the env variables in `tests/peregrine-dip-consumer-template/.env.develop.test` for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and in `tests/dip-provider-template-dip-consumer-template/.env.develop.test` for `PROVIDER_IMAGE` to `kiltprotocol/dip-provider-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc`. * Run `yarn test:e2e:start-network:peregrine-provider:develop` to spin up the Zombienet network for Peregrine <-> DIP consumer * In a different bash, run `yarn test:e2e:peregrine-provider` to run the integration tests * Same thing with `yarn test:e2e:start-network:dip-template-provider:develop` and `yarn test:e2e:dip-template-provider`.
DIP consumers are specific to a given provider. Right now, the template provider uses `u32` as block numbers, while `Peregrine` uses `u64`. This means that it is not possible to use a single consumer runtime (hence Docker image) to test both providers. The issue is fixed by making the provider template use the same block number type as Peregrine, so we can "stretch" it to be used in integration tests against the template consumer without having to have two different consumer runtimes and Docker images. To keep it consistent (although it is not required), I also changed the consumer runtime to use `u64`s. Integration tests with the DIP-SDK are finally passing. You can run them yourself following the instructions below. ## Checklist - [x] Apply change - [x] Build and push temp Docker images - [x] Verify integration tests for same template consumer work with both template provider and Peregrine - [ ] Review PR ## How to test * Clone the [DIP-SDK repo at this branch for PR #3](KILTprotocol/dip-sdk#3) * Set the env variables in `tests/peregrine-dip-consumer-template/.env.develop.test` for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and in `tests/dip-provider-template-dip-consumer-template/.env.develop.test` for `PROVIDER_IMAGE` to `kiltprotocol/dip-provider-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc` and for `CONSUMER_IMAGE` to `kiltprotocol/dip-consumer-node-template:dev-release-48c2c610d7c6a91f9c1579c8a93d12c59b35b6cc`. * Run `yarn test:e2e:start-network:peregrine-provider:develop` to spin up the Zombienet network for Peregrine <-> DIP consumer * In a different bash, run `yarn test:e2e:peregrine-provider` to run the integration tests * Same thing with `yarn test:e2e:start-network:dip-template-provider:develop` and `yarn test:e2e:dip-template-provider`.
Integrates https://github.com/paritytech/zombienet/releases/tag/v1.3.85 which includes deterministic pord forwarding for Kubernetes-based environments.## Blocked by paritytech/zombienet#1578Partially fixes https://github.com/KILTprotocol/ticket/issues/3057.
Because of the Zombienet blockers, this PR has morphed into one that adds support for Peregrine.
Checklist