Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Test the deployment check script, including the ways it fails

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
bash, shell
Domain
ci-cd, testing

Research direction

Start by reading scripts/verify-deployment.sh to see how it chooses exit codes 0, 1 and 2, and how it calls stellar contract fetch and sleep 5. Then write scripts/test-verify-deployment.sh with a fake stellar first on PATH and a temporary copy of the repo files, covering the five cases. Done when bash scripts/test-verify-deployment.sh passes, the build job in .github/workflows/ci.yml runs it, and a mutated script that exits 0 on mismatch makes it fail.

Written by the indexing model from the issue text.

Description

enhancement help wanted

Written against commit a23a8df; later commits may have moved things, so check the code first.

Size: Medium

Description
scripts/verify-deployment.sh is the guard that tells a reader whether the Sorogate contract on Testnet is still the code the
tests ran against, and CI runs it weekly. Its three outcomes (match, different, unreachable) were checked by hand once. Nothing
re-checks them, so a later edit could make a failure look like a pass and CI would stay green.

Current state
The script exits 0 when the network's code matches the pin in tests/fixtures/access_policy.wasm.sha256, 1 when the
fixture is not the pinned file or the network holds different code, and 2 when it cannot fetch after three tries. It calls
stellar contract fetch, retries with sleep 5, and prints both hashes on a mismatch. The deployment job in
.github/workflows/ci.yml runs it against the real network, so only the success path is ever exercised in CI, and a failure
mode can only be observed by breaking something on purpose.

What to build
A shell test, for example scripts/test-verify-deployment.sh, that runs the real script against a fake stellar placed first on
PATH, so no network is needed. The fake writes a file you choose, or fails. The retry delay needs to be overridable (an
environment variable, or a fake sleep) so the "unreachable" case does not take ten seconds. Cases:

  1. network code equals the pin: exit 0, and the output names the contract and the hash;
  2. the fixture file has been altered: exit 1, before any fetch;
  3. the network returns different bytes: exit 1, and both hashes are printed;
  4. the fetch fails every time: exit 2, after exactly three attempts;
  5. the fetch fails once, then succeeds: exit 0.
    Run the test in CI in the build job, which does not touch Testnet.

Acceptance criteria

  • All five cases above are tested, each asserting the exit code and a key part of the message.
  • The test uses no network and a temporary copy of the repository files, and leaves nothing behind.
  • It fails if verify-deployment.sh is changed so that a mismatch exits 0 (show this in the PR).
  • It runs in CI, and the README or CONTRIBUTING.md lists it with the other checks.

Out of scope
Replacing the script's logic, or testing stellar contract fetch itself.

Verification
bash scripts/test-verify-deployment.sh.

Dominant language
Rust
Stars
2
Forks
2
Avg merge
49m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Sorogate/example-consumer

All issues in Sorogate/example-consumer

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.