Conversation
Member
|
@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
Member
|
@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. |
ntn-x2
changed the title
4 tasks
ntn-x2
added a commit
to KILTprotocol/kilt-node
that referenced
this pull request
Dec 19, 2023
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`.
Dudleyneedham
approved these changes
Dec 19, 2023
| .vscode | ||
|
|
||
| # Tests | ||
| .env.* |
Member
There was a problem hiding this comment.
Why are we getting rid of this?
Contributor
Author
There was a problem hiding this comment.
Because I think it's better to have them in, as they will be used by the CI as well. It does not hurt.
ntn-x2
force-pushed
the
aa/zombienet-update
branch
from
ffb3e35 to
15da2b1
Compare
Ad96el
pushed a commit
to KILTprotocol/kilt-node
that referenced
this pull request
Jan 10, 2024
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`.
Ad96el
pushed a commit
to KILTprotocol/kilt-node
that referenced
this pull request
Feb 7, 2024
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`.
Ad96el
pushed a commit
to KILTprotocol/kilt-node
that referenced
this pull request
Apr 2, 2024
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`.
hacker-nova7431
added a commit
to hacker-nova7431/kilt-node
that referenced
this pull request
Sep 29, 2025
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`.
infra-riderju74
added a commit
to infra-riderju74/kilt-node
that referenced
this pull request
Oct 27, 2025
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`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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