[Audit #80] commitlint CI step runs with continue-on-error: true, never enforcing the convention

[afurious]

Description

CONTRIBUTING.md sets an explicit expectation for contributors: "Commit messages must follow conventional commits format," followed by a list of the accepted prefixes (feat:, fix:, docs:, test:, ci:, chore:). Backing that up, the repository ships a .commitlintrc.json configuration and wires wagoid/commitlint-github-action into the main Rust CI workflow specifically to check every PR's commit messages against that convention automatically, rather than relying on manual review discipline. On paper, this is a complete enforcement story: a documented rule, a machine-readable config for it, and an automated check that runs on every PR.

In practice, the automated check is configured to never have any consequence. The Lint commit messages step in rust_ci.yml is marked continue-on-error: true, which means GitHub Actions records and displays whatever pass/fail result the linter produces, but treats the overall job as successful either way — a failing commitlint run does not block a merge, request changes, or fail any required status check. The convention is real, the tooling to check it is real and correctly configured, but the one piece that would actually make it binding was left permissive, so the net effect today is identical to not running the linter at all. The gap isn't purely theoretical: the current commit history already contains messages that don't conform to the documented convention, which is exactly what unenforced linting predicts.

Severity

severity: medium — documentation/process drift; the convention exists on paper and in tooling but isn't enforced in practice.

Location

.github/workflows/rust_ci.yml (~L33–36):

- name: Lint commit messages
  uses: wagoid/commitlint-github-action@v6
  continue-on-error: true
  with:
    configFile: .commitlintrc.json

Requirements and context

• CONTRIBUTING.md states: "Commit messages must follow conventional commits format," and .commitlintrc.json exists specifically to enforce that — but the CI job is configured to always report success regardless of what the linter finds.
• Failure scenario: A contributor pushes a commit that violates the conventional-commits format. The Lint commit messages step visibly fails in the Actions UI, but the overall job still reports green and the PR merges cleanly, silently degrading whatever changelog/release-automation value the convention exists to support. Drift already exists in the current history — e.g. 537ccbcd Fix batch-transfer fund-lock on blocklisted SEP-41 addresses uses a capitalized, non-conventional subject line that would fail commitlint's default rules.

Suggested execution

Fork the repo and create a branch

git checkout -b fix/enforce-commitlint

Implement changes

• Remove continue-on-error: true from the Lint commit messages step in rust_ci.yml so a failing lint actually fails the job.
• Before flipping it, run commitlint locally against a sample of recent history to gauge how much grandfathering is needed; if enforcement should only apply going forward, scope it to lint only commits since a fixed point rather than the entire PR range, or explicitly document in CONTRIBUTING.md that older history is exempt.
• If, after review, the intent is genuinely advisory-only rather than enforced, take the opposite fix: update CONTRIBUTING.md to say "should" instead of "must" so the docs match reality. Pick one direction — the current state, where both exist and disagree, is what this issue is about.

Test and commit

• Push a deliberately non-conventional commit message on a scratch branch/PR to confirm the CI job now actually fails, then verify a conventional one passes, before merging the workflow change itself with a compliant commit message.

cargo test --workspace   # unaffected, but confirms nothing else broke

Example commit message:

fix(ci): enforce commitlint instead of continue-on-error

Guidelines

• Branch off main.
• Reference this issue with Closes #<issue-number> in your PR.
• Whichever direction is chosen (enforce vs. relax the docs), make sure .commitlintrc.json, rust_ci.yml, and CONTRIBUTING.md all agree afterward — partial fixes just move the inconsistency rather than closing it.

[MusaTheDev001]

I’d like to work on this issue because it is a clear and focused CI improvement with a practical impact on repository consistency. The documentation and commitlint configuration already establish the intended convention, so the main task is to make the existing check enforceable by removing continue-on-error: true and validating the behavior with both compliant and non-compliant commits. I’ll also review recent commit history to understand whether any adjustment to the linting scope is needed, run the relevant tests, and ensure CONTRIBUTING.md, .commitlintrc.json, and rust_ci.yml remain aligned. I’ll keep the change minimal, reference the issue in the PR, and use a conventional commit message for the implementation itself.

[grantfox-oss]

🦊 GrantFox — @MusaTheDev001 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #1382)
2. Your PR will be reviewed by the Crowdfunding-DApp maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@MusaTheDev001's PR #1384 was approved and merged by @afurious.

🏆 @MusaTheDev001: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (309 total points). Track your full progress on GrantFox.

👏 Great work, @MusaTheDev001! Keep contributing to Crowdfunding-DApp.