Skip to content

fix: Cargo.lock not committed — reproducible builds not guaranteed #806

Description

@sanmipaul

Bug

If `contracts/Cargo.lock` is listed in `.gitignore` or not committed to the repository, dependency versions are resolved fresh on every `cargo build`. This means:

  1. CI builds today and tomorrow may use different minor/patch versions of crates
  2. A dependency update (even a patch version) can break the build with no code changes
  3. Security audit results are invalid because the exact dependency tree is unknown
  4. Reproducible builds are impossible

Check

```bash
git ls-files contracts/Cargo.lock

If this returns nothing, Cargo.lock is not tracked

```

Fix

For binary/application crates (contracts are treated as binaries by Soroban), `Cargo.lock` MUST be committed:

```bash

Remove from .gitignore if present

Then:

git add contracts/Cargo.lock
git commit -m "chore: commit Cargo.lock for reproducible builds"
```

Also add a CI step that verifies the lock file is up to date:

```yaml

  • name: Verify Cargo.lock is up to date
    run: cargo update --locked
    ```

Acceptance Criteria

  • `contracts/Cargo.lock` committed to repository
  • `contracts/Cargo.lock` not in `.gitignore`
  • CI uses `--locked` flag in all cargo commands
  • `CONTRIBUTING.md` instructs contributors to commit `Cargo.lock` changes
  • Dependabot configured to update `Cargo.lock` automatically (see companion issue)

References

  • `contracts/`
  • `.gitignore`
  • `.github/workflows/ci.yml`

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programbugSomething isn't workingdevopsCI/CD and infrastructuretoolingCI, scripts, dev tooling

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions