ci: add integration tests for write-program-buffer

[sparten11740]

When I worked on the program extension fix for the write-proram-buffer action last week (#22), it would’ve been great to have automated tests running in the CI to increase confidence in the solution. I was trialing a few test scenarios and a way of testing this against a local solana validator. I think this could be helpful for future changes.

These are the scenarios tested for the write-program-buffer action (the workflow has a path filter, so they don’t run on changes to the other actions):

• fresh — program not deployed yet: buffer created, contents match the artifact byte-for-byte, buffer authority stays with the deployer, resize and authority transfer skipped
• delta — deployed program grows by more than 10,240 bytes: account extended by exactly the computed delta
• clamp — deployed program grows by less than 10,240 bytes: extend clamped up to the SIMD-0431 minimum of 10,240
• authority — same-size artifact with an external buffer-authority-address: buffer authority transferred on-chain, no resize
• nearmax — program within 10 KiB of the 10 MiB cap: extend equals exactly the remaining headroom, landing the account at the maximum size

Test fixtures are prebuilt binaries, reproducible byte-for-byte from tests/fixtures/program/ via rebuild.sh. Also extracts start-test-validator as a reusable action (not documented yet, lmk if you’d like that added as part of the public set of actions)

[greptile-apps]

Greptile Summary

This PR adds a full integration test suite for the write-program-buffer action, running five scenarios (fresh, delta, clamp, authority, nearmax) against a local solana-test-validator on each PR. It also extracts a reusable start-test-validator composite action.

• Workflow + fixtures: A matrix CI job (test-write-program-buffer.yaml) orchestrates prepare → action → assert per scenario; binary fixtures are prebuilt and reproducible via rebuild.sh, with size-band invariants enforced at build time.
• Scenario scripts: Each prepare-*.sh handles keygen, airdrop, optional pre-deploy/extend, and slot-advance waits; matching assert-*.sh scripts verify program data length growth, buffer contents byte-for-byte, and buffer authority on-chain.
• start-test-validator: Composite action launches the validator in the background with --reset, uses nick-fields/retry for health polling, and dumps logs on failure.

Confidence Score: 5/5

Safe to merge — all five test scenarios are logically sound, fixture invariants are validated at build time, and the new start-test-validator action is a thin, well-guarded wrapper.

The prepare/assert pairing is consistent across all scenarios, size-band checks in both rebuild.sh and the prepare scripts guard against fixture drift, and the slot-advance waits are applied only where program extension is involved. The only fragility is the hardcoded CLI error string in assert-fresh.sh, which is stable while the Solana version stays pinned.

Files Needing Attention: assert-fresh.sh — the program-absence check depends on a specific Solana CLI error message string that would silently invert on a version bump.

Important Files Changed

Filename	Overview
.github/workflows/test-write-program-buffer.yaml	New CI workflow running all 5 integration scenarios in a matrix against a pinned Solana version; path filters, concurrency guard, and log-dump-on-failure are all present and correct.
start-test-validator/action.yaml	New reusable composite action that starts solana-test-validator in the background; uses shell: bash -euo pipefail {0}, nick-fields/retry health check, and dumps logs on failure.
write-program-buffer/tests/integration/assert-fresh.sh	Asserts buffer contents, deployer authority, and program non-existence; the absence check relies on the CLI string "Unable to find the account" which could silently invert the assertion on a version change.
write-program-buffer/tests/integration/prepare-nearmax.sh	Sets up the near-max scenario by decompressing the huge fixture, computing headroom, deploying small.so, and extending to exactly TARGET_CURRENT = HUGE_SIZE - 2000; drift guards and a slot-advance wait are included.
write-program-buffer/tests/integration/assert-nearmax.sh	Verifies that POST_LEN equals MAX_PROGRAM_SIZE (10485715) and buffer contents match the decompressed huge artifact; consistent use of
write-program-buffer/tests/fixtures/rebuild.sh	Reproducible build script for all four size fixtures; enforces size-band invariants for each variant and gzip-compresses the huge fixture for storage efficiency.
write-program-buffer/tests/integration/prepare-clamp.sh	Validates big-small delta is in (0, 10240), deploys small.so, captures PRE_LEN, waits for slot advancement before handing off to the action.
write-program-buffer/tests/integration/prepare-authority.sh	Generates a third keypair as the authority-transfer target, deploys small.so, and outputs buffer-authority=AUTHORITY_TARGET so the action can verify a real cross-account authority transfer.

Sequence Diagram

sequenceDiagram
    participant CI as GitHub Actions Runner
    participant V as solana-test-validator
    participant Chain as On-chain State

    CI->>CI: checkout + setup-all (install Solana CLI)
    CI->>V: start-test-validator (--reset, background)
    V-->>CI: rpc-url + ledger-dir outputs
    CI->>CI: "prepare-{scenario}.sh (keygen, airdrop, optional deploy/extend)"
    CI->>V: solana airdrop / program deploy / program extend
    V-->>Chain: lamports + ProgramData account
    CI->>CI: outputs: keypair, program-id, pre-len, buffer-authority

    CI->>CI: write-program-buffer action
    CI->>V: create buffer, write bytes
    note over CI,V: if needed: extend program account
    V-->>Chain: buffer account + optional program resize + optional authority
    CI-->>CI: output: buffer address

    CI->>CI: "assert-{scenario}.sh"
    CI->>V: solana program show (POST_LEN)
    CI->>V: solana program dump (buffer to tmpfile)
    CI->>CI: cmp artifact vs dump
    CI->>CI: check authority / program existence / size delta

    note over CI: On failure: tail validator-stdout.log + validator.log

Loading

_{Reviews (4): Last reviewed commit: "fix: address 2nd round of reviews (#6)" | Re-trigger Greptile}

[sparten11740]

@Woody4618 lmk if this is a direction you're okay with (absolutely no problem if you prefer not to)

[dev-jodee]

looks good, couple of questions

[dev-jodee]

Should we have deployer and buffer-auth be the same keypair? or sohuld it be different

[sparten11740]

You mean so we can test that buffer-auth stays with the deployer on initial deployment? i.e. to exercise a test for this if?:

    - name: Transfer buffer authority
      if: steps.check-program.outputs.exists == 'true'

No strong opinion. I feel this is okay given that these are not unit tests that cover every detail