fix(devnet): resolve upgrade script paths relative to the script, not the caller

[mateeullahmalik]

Problem

devnet/scripts/upgrade.sh cannot drive an upgrade when invoked from the repository root — which is how the rehearsal flow is documented and how make devnet-upgrade-* reaches it. It fails with two claims that are both false:

⚠️  Governance helper account lumera1kd5... is not present on-chain; using primary validator proposer.
❌ Unable to resolve fallback proposer key supernova_validator_1_key

I checked both against the live devnet: the account held 1,000,000 LUME and the key was in the container keyring. Only the compose lookup was broken.

Root cause

submit-upgrade-proposal.sh and vote-all.sh both hardcoded a caller-relative path:

COMPOSE_FILE="../docker-compose.yml"

That resolves only from devnet/scripts/. From anywhere else every docker compose -f "$COMPOSE_FILE" exec ... failed, so key_address() and account_exists() returned empty and the scripts blamed governance/keyring state.

This failure mode is expensive out of proportion to its size: the error text points at the chain, so you go debugging accounts and keyrings instead of a path.

Isolating proof

Same script, same devnet, same arguments — only the working directory differs:

Invoked from	Result
devnet/scripts/	Governance proposer: governance_key (lumera1rmr8…) → proceeds
repository root	not present on-chain → exit 1

Fix

Resolve from BASH_SOURCE, keeping an env override:

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
COMPOSE_FILE="${COMPOSE_FILE:-${SCRIPT_DIR}/../docker-compose.yml}"

Second defect: branch builds can't pass the version probe

upgrade-binaries.sh refuses to proceed unless <binary> version prints something. Binaries built from a branch with plain go build (no -ldflags) print nothing, so rehearsing an unreleased branch was impossible:

Failed to determine version for binary: .../devnet/bin-v1.20.2/lumerad

Confirmed empirically — release v1.20.1 prints 1.20.1; a local branch build prints "". Added a DEVNET_BINARY_VERSION override plus an error message that names it. Release artifacts self-report and are unaffected.

Third defect: found, deliberately NOT fixed here

During the end-to-end run:

❌ supernova_validator_2: fee top-up failed: account sequence mismatch, expected 2, got 1
❌ Skipping vote for supernova_validator_2 because fee top-up failed
📈 Total Votes Cast: 4000000000000     (4 of 5 validators)

Back-to-back top-ups from one funding account race the sequence number, and the script silently drops that validator's vote. The proposal still passed here, but on a network where one validator carries decisive weight this could silently change a governance outcome. It needs a sequence-aware retry and deserves its own PR. Documented in the commit so it isn't rediscovered from scratch.

Evidence — full E2E after the fix

Fresh 5-validator devnet at v1.20.1, upgrading to a branch-built v1.20.2, invoked from the repository root:

Governance proposer: governance_key (lumera1rtk...)   <- previously failed here
Total Votes Cast: 4000000000000
Binaries upgrade complete
Upgrade to v1.20.2 initiated successfully
exit code 0

q upgrade applied v1.20.2 ...... height 121
audit module version ........... 3
all 5 validators ............... height 175, in lockstep

bash -n and shellcheck -S error clean on all three files.

Correction to an earlier claim of mine

I previously reported that upgrade.sh "exits 0 on failure". That was my measurement error — I read $? after piping stdout to tail, so I was reading tail's status. upgrade.sh sets set -euo pipefail and correctly returns 1. No change was needed and none was made.

Risk / rollback

Shell-only, confined to devnet tooling — no chain code, no state machine, no consensus path. The env-var indirection preserves any existing COMPOSE_FILE override. Rollback: revert; the scripts return to working only from devnet/scripts/.

---

Found while running the Phase 1 upgrade rehearsal for #199, where I had to drive the governance flow by hand to work around it.