Simplify E2E Configuration

[chatton]

Summary

Depends on this issue for more granular relayer configution.

Currently we configure E2E tests with both environmental variables, and with a configuration file

The environment variables take precedence over the config files and are used to dynamically specify things like docker tags, relayer type etc.

This works, but can be simplified quite a lot. The only values that actually 100% need to be dynamic are CHAIN_A_TAG, CHAIN_B_TAG and ACTIVE_RELAYER. Everything else can actually be static.

Because of this, I suggest we create 1 configuration file per type of test, and override only the bare minimum of values. This will reduce the likely hood of error when passing fields throughout workflows, and also create a single source of truth for things such as the relayer image/version.

Currently there is some defaulting going on in the workflows and also in the code.

We can move all defaults into config files instead of the code.

A sample config might look like

---
chains:
  # the entry at index 0 corresponds to CHAIN_A
- chainId: chain-a
  numValidators: 4
  numFullNodes: 1
  image: ghcr.io/cosmos/ibc-go-simd
  tag: main # override with CHAIN_A_TAG
  binary: simd

  # the entry at index 1 corresponds to CHAIN_B
- chainId: chain-b
  numValidators: 4
  numFullNodes: 1
  image: ghcr.io/cosmos/ibc-go-simd # override with CHAIN_IMAGE
  tag: main # override with CHAIN_B_TAG
  binary: simd

relayers:
  activeRelayer: hermes # ACTIVE_RELAYER 
  configurations:
  - relayer: hermes
    image: "ghcr.io/informalsystems/hermes"
    tag: 1.4.0
  - relayer: rly
    id: rly 
    image: "ghcr.io/cosmos/relayer"
    tag: latest 
cometbft:
  logLevel: info

debug:
  dumpLogs: false

upgrade:
  planName: ""
  tag: ""

Then on our workflows, we pass just ACTIVE_RELAYER, CHAIN_A_TAG, CHAIN_B_TAG.

It may be possible add a list of upgradeConfigurations as all plan names and tags are already known. And in a test, we specify an UPGRADE_ID or similar.

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged/assigned

[damiannolan]

@chatton is this issue addressed now?

[chatton]

not quite, the simplification I'm referring to in this issue is about how the CI runs the tests (they still use a lot of env vars).

Locally we can specify a configuration file, but in the tests they are using env vars still.