33 lines
3.7 KiB
Markdown
33 lines
3.7 KiB
Markdown
# Gitea repository and delivery
|
|
|
|
Owner-provided account: [gitea.samialabri.com/sami](https://gitea.samialabri.com/sami). The owner approved Wristivo and the `wristivo` slug on 2026-09-16 and will create the repository. **No remote repository has been created or pushed by this foundation task.** Agreed repository slug: `wristivo`; visibility: private. Existing authenticated sessions/SSH agent or the system credential manager should handle authentication; never paste access tokens into agent chat or commit them.
|
|
|
|
## Owner creates an empty private repository
|
|
|
|
Create `sami/wristivo` on that server, private, with default branch `main`. Leave README/license/gitignore initialization off because this repository already supplies them. Do not choose an open-source license until the intended rights model is decided. Copy the exact HTTPS or SSH clone URL from Gitea; SSH usernames/ports are deployment-specific.
|
|
|
|
The integrating engineer then verifies the destination and existing refs, adds `origin` to this local repository, and pushes `main` normally. For the expected HTTPS deployment the candidate URL is `https://gitea.samialabri.com/sami/wristivo.git`, but use the server's displayed clone URL as authoritative.
|
|
|
|
```sh
|
|
# From the local Wristivo repository, after owner creates it:
|
|
git remote add origin https://gitea.samialabri.com/sami/wristivo.git
|
|
git ls-remote origin
|
|
git push -u origin main
|
|
```
|
|
|
|
If the remote is not empty, inspect and integrate its existing history first; do not force-push or overwrite it. If origin already exists, inspect it before changing anything. Never put a token in the URL. Remote creation/push are pending, not failed or completed.
|
|
|
|
## Collaboration controls
|
|
|
|
Protect main after initial bootstrap: PR-based changes, required successful validation check once configured, no force pushes/deletion, and at least one integration review where the account/team setup permits. Keep the integration role explicit even when a sole owner is both author and reviewer. Feature branches follow docs/agents/README. Use PR template and small milestone labels: foundation, pairing, relay, gestures, experience, release; and needs-hardware, blocked-contract, security-review.
|
|
|
|
## CI
|
|
|
|
`.gitea/ci.yml.example` is intentionally a template until server/runner versions and trust settings are confirmed. Enable Actions for the repository, provision a dedicated trusted macOS host runner with Xcode and required runtime tools, label it `macos-wristivo`, validate its checkout/action support, then copy the file to `.gitea/workflows/ci.yml`.
|
|
|
|
Apple builds require macOS/Xcode; a generic Linux container cannot compile the app targets. A host runner executes code on its machine, so do not give an untrusted fork automatic access to a signing machine or home-network TV. The template runs trusted branch pushes and manual requests. Add PR validation only after reviewing runner isolation and who can submit code. No Apple signing secrets are required for these unsigned tests/builds.
|
|
|
|
The template pins checkout v4.2.2 to a verified commit rather than a movable tag. Check current security advisories and Gitea compatibility before activating; this is not a claim it is the newest release. Review/record future tool updates. Network access to the action source is required unless mirrored with verified provenance. The runner's registration token belongs in runner configuration/secrets, never git.
|
|
|
|
Sources checked 2026-09-16: [Gitea runner overview](https://docs.gitea.com/runner/), [Gitea API reference](https://docs.gitea.com/api/1.24/), [pinned checkout commit](https://github.com/actions/checkout/commit/11bd71901bbe5b1630ceea73d27597364c9af683). Use documentation matching the actual server/runner versions; neither version has been inspected on the owner's server.
|