You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the CI tests that we have inside polkadot-sdk use the runtimes from polkadot-sdk, and the relayer release from parity-bridges-common. The problem with this approach is that when we make a change to the relayer, the CI doesn't actually test it on the spot. For this kind of changes we have to run the tests locally manually.
We should create a Rococo <> Westend relayer flavor inside polkadot-sdk in order to address this limitation. For convenience we can also keep the Rococo <> Westend flavor inside the parity-bridges-common.
The text was updated successfully, but these errors were encountered:
I think maintaining parity-bridges-common "mirrored" code in polkadot-sdk is more cumbersome/expensive than having to sanity check relayer changes using local testing before publishing new version.
This would also make the R<>W relayer development&deployment process different than the P<>K relayer, which again adds more maintenance complexity.
Closing it. Please reopen if you strongly disagree.
Related to #2950
Right now the CI tests that we have inside
polkadot-sdk
use the runtimes frompolkadot-sdk
, and the relayer release fromparity-bridges-common
. The problem with this approach is that when we make a change to the relayer, the CI doesn't actually test it on the spot. For this kind of changes we have to run the tests locally manually.We should create a Rococo <> Westend relayer flavor inside
polkadot-sdk
in order to address this limitation. For convenience we can also keep the Rococo <> Westend flavor inside the parity-bridges-common.The text was updated successfully, but these errors were encountered: