You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,6 +59,7 @@ CI note
59
59
- Do not alter seed handling, signing, or cryptography without maintainer approval.
60
60
- Runtime registries and chain/type sources must be aligned with the current Polkadot SDK release; coordinate updates with maintainers.
61
61
- Use `*.xcconfig` and environment variables for private values; avoid hardcoding secrets in `Info.plist`.
62
+
- Keep partner identifiers and buy-provider keys in environment variables or generated CI keys, not committed Swift source.
62
63
63
64
## Dependencies & Versioning
64
65
- Prefer conservative upgrades (patch/minor). Pin major bumps to separate PRs with clear testing notes.
@@ -149,6 +150,7 @@ The project mixes CocoaPods and Swift Package Manager. Follow these steps in ord
149
150
- Environment variables:
150
151
-`GH_PAT_READ` (optional): GitHub PAT for private pods (`FearlessKeys`).
151
152
-`DEVELOPER_DIR` (optional): Jenkinsfile auto‑pins to Xcode 15.x if present for SPM stability; otherwise default Xcode is used.
153
+
-`MOONPAY_PUBLIC_KEY`: Moonpay partner public key generated into CI keys for trusted builds.
152
154
- Private keys in PRs:
153
155
- PR builds do NOT require private keys. The Jenkinsfile detects PR context (`CHANGE_ID`) and temporarily comments out the `pod 'FearlessKeys'` line before `pod install`, then restores the file. This prevents private repo access and allows PRs to build without secrets.
154
156
- Trusted branches (develop/master/release): Jenkins sets `INCLUDE_FEARLESS_KEYS=1` and, if `GH_PAT_READ` is present, rewrites GitHub URLs to use the token so `pod install` can fetch `FearlessKeys`.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+21-3Lines changed: 21 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,25 @@ If you think you miss some functionality on our application, please open issue o
27
27
* (OPTIONAL) If possible, provide complete description of functionality you suggest
28
28
* (OPTIONAL) Provide your telegram username, and be sure to join [Our Community Channel](https://t.me/fearlesshappiness) on Telegram, so our team can get in touch with you to retrieve more information about your vision
29
29
30
-
Even if you provide mockups, please understand that our design team will review it and might implement this in very different way.
30
+
Even if you provide mockups, please understand that our design team will review it and might implement this in very different way.
31
+
32
+
### Git flow
33
+
34
+
All normal work starts from `develop` and is submitted back to `develop`.
35
+
Use short-lived branches named `feature/<ticket>-<slug>`, `fix/<ticket>-<slug>`,
36
+
`chore/<slug>`, or `refactor/<slug>`.
37
+
38
+
`master` is the releasable branch. Do not target `master` except for release
39
+
pull requests from `develop` or urgent `hotfix/<version-or-slug>` branches.
40
+
Every commit on `master` must be safe to release, and release tags must point at
41
+
commits already merged to `master`.
42
+
43
+
Feature PRs are squash-merged after review and green CI. Release PRs to
44
+
`master` use merge commits so the release boundary remains visible.
45
+
46
+
The `Branch Flow` GitHub Actions workflow validates PR targets automatically:
47
+
normal work must target `develop`, while `master` accepts only `develop`,
48
+
`release/*`, or `hotfix/*` branches.
31
49
32
50
### 💻 Opening Pull Requests
33
51
@@ -36,10 +54,10 @@ If you would like to help us by contributing writing the code, please follow nex
36
54
* Always create and issue prior to opening Pull Request (hereinafter the PR), or your PR less likely to be reviewed
37
55
* Remember, that in that case you are required to provide full description for you feature in created issue, otherwise it would be hard for us to understand what you're trying to add to our codebase
38
56
* Follow the coding standards guidelines (TO BE PROVIDED LATER), or you will be asked to make changes to follow them
39
-
* Please avoid huge PRs, and if your contribution really requires lots of files, please make a base branch with series of small PRs on your fork, and then provide link to those PRs in your big one PR in our repository
57
+
* Please avoid huge PRs, and if your contribution really requires lots of files, please make a base branch with series of small PRs on your fork, and then provide link to those PRs in your big one PR in our repository
40
58
* Provide steps for QA engineer to test your functionality (they should cover requirements from your issue)
41
59
42
-
Even if you provide mockups, please understand that our design team will review it and might implement this in very different way.
60
+
Even if you provide mockups, please understand that our design team will review it and might implement this in very different way.
0 commit comments