Allow different chain executables to be used during integration test

[soareschen]

Summary

We should be able to specify multiple chain executables, e.g. gaia5 and gaia6, and use them to initialize different chains in the binary and N-ary tests.

Problem Definition

Currently the chain executable is gaiad by default, and can be overridden using CHAIN_COMMAND_PATH. However the integration test still allows only one executable to be used at a time.

We should instead allow the chain executable to be customized in a plural form, e.g. CHAIN_COMMAND_PATHS=gaiad5,gaiad6. This would allow the integration test to run with one chain being Gaia v5, and the other chain being Gaia v6.

Proposal

Modify the chain command path from a single String into Vec<String>. If the vector is empty, use gaiad as the executable by default. Otherwise for each chain position N, access the N-th position of the vector modulo the vector length.

For example, the following arrays will use the executable at the N-th chain:

• ["gaiad"] - gaiad, gaiad, gaiad, ...
• ["gaiad5", "gaiad6"] - gaiad5, gaiad6, gaiad5, gaiad6, ...
• ["gaiad5", "gaiad6", "gaiad7"] - gaiad5, gaiad6, gaiad7, gaiad5, gaiad6, ...

This is mainly applicable for the N-ary test cases, where there can be more than 2 chains required.

Acceptance Criteria

Running the following should use gaiad5 and gaiad6 in test_ibc_transfer:

CHAIN_COMMAND_PATHS=gaiad5,gaiad6 cargo test -p ibc-integration-test -- test_ibc_transfer

Running the following should use gaiad5, gaiad6, and gaia7 in test_ternary_ibc_transfer:

CHAIN_COMMAND_PATHS=gaiad5,gaiad6,gaiad7 cargo test -p ibc-integration-test -- test_ternary_ibc_transfer

Note that if you are installing Gaia from Cosmos.nix, the current way to get multiple versions of Gaia is by getting the absolute path, i.e.:

GAIA6=$(nix shell github:informalsystems/cosmos.nix#gaia6 -c which gaiad)

We will figure out setting up Nix shells with multiple version of Gaia in Cosmos.nix in the future.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[soareschen]

This would be useful for testing issues such as #2433, where the problem with relaying occur when connecting between two different chain implementations.

[soareschen]

@ljoss17 it seems like the changes here probably introduced too many jobs and choked the CI. Can you reduce the combinations to just a handful for now?

[soareschen]

Nvm, it is a different issue. #2928