jamditis/stash
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Document repository features, setup boundaries, and co-op compute questions

jamditis committed 2026-10-16 20:52:42 +00:00
1 parent 094169dbcd
commit bb4d152b3d
1 file changed
+54
Download Patch File Download Diff File Expand all files Collapse all files
Feature-guide.md
+54
@@ -0,0 +1,54 @@
# Gitea feature guide
Checked October 16, 2026. This guide separates platform features from services the hosting cooperative has actually documented.
## Repository tabs
| Tab | What it is for | Stash setup |
| --- | --- | --- |
| Code | Git files, branches, diffs, history, clone/download | README and reusable project scaffolding proposed in PR #1. |
| Issues | Problems, ideas, labels, milestones, dependencies and time tracking | Existing labels retained; Kind/Experiment added. Templates are in PR #1. |
| Pull requests | Review branch changes before merging | PR #1 is linked to the workbench in Review. |
| Actions | Run checks and other workflows on a runner | Enabled; no workflows yet; repository settings show no available runners. |
| Packages | Publish and consume packages linked to the repository | Available, empty. Packages belong to their user/organization owner. |
| Projects | Kanban columns containing issues and pull requests | Stash workbench created with a Review stage. |
| Releases | Tagged versions, release notes and artifacts | Available, empty until there is a meaningful version. |
| Wiki | Git-backed handbook separate from code | Home and this guide. |
| Activity | Pulse, contributors, code frequency and recent commits | Read-only reporting; distinct from the audit log. |
## Settings map
- **Repository:** description, website, feature tabs, mirror options, merge styles, and archive/transfer controls. Keep ordinary experiments on branches. Do not set up a mirror without checking the source's publication rights and history.
- **Collaborators:** named access grants. Public reading does not require adding collaborators.
- **Webhooks:** send repository events to another service. Choose a specific destination, minimal events, and signature verification when an integration is needed.
- **Branches and tags:** protection rules. Avoid requiring a nonexistent CI check or an approval a solo maintainer cannot obtain.
- **Deploy keys:** machine access. Public cloning does not require a new key or token.
- **Actions / General:** enablement and token permissions. Read-only defaults suit validation; write permissions should be deliberate.
- **Actions / Runners:** machines that execute jobs. Verify operator, labels, trust, isolation, capacity and costs.
- **Actions / Secrets:** protected configuration for a named integration. Never place secrets in issues or source files.
- **Actions / Variables:** non-secret workflow configuration. Add values only when a workflow uses them.
- **Audit log:** security-related events when server recording is enabled. An empty log does not prove no activity occurred.
## Differences worth knowing coming from GitHub
Git history remains portable. Gitea Actions uses familiar workflow concepts, but compatibility is incomplete; review workflows before copying them. An enabled Actions tab does not provide compute on its own. Projects here are Kanban boards rather than a promise of every GitHub Projects view or automation. Packages have owner-level relationships. Do not assume GitHub Pages-style website hosting is included.
The co-op documents public reading and membership-linked sign-in. Outside contributors may need membership to participate through this instance.
## Costs and shared compute
The co-op publishes sliding-scale dues starting at $5 USD/month, with $15 suggested. Membership includes $15/month of shared AI chat/API credit. Extra non-expiring credit packs start at $5. These are inference allowances, not documented CI minutes or GPU-hours.
No Git-specific hosting surcharge, repository/LFS/package quota, CI-minute price, or general-purpose GPU-job service was established from the reviewed public docs. Do not assume unlimited capacity.
A member-operated Gitea runner could supply build/test capacity if the co-op permits it. It would not automatically contribute to an AI inference pool. Shared runners execute other people's code: isolation, operator trust, secrets handling, fair-use limits and maintenance need a deliberate design. The public docs leave infrastructure ownership and institutional compute contributions open for discussion; no self-service hardware donation program was verified.
## Sources
- [Co-op getting started](https://git.inference.coop/co-op/docs/src/branch/main/getting-started.md)
- [Co-op infrastructure](https://git.inference.coop/co-op/docs/src/branch/main/infrastructure.md)
- [Open questions](https://git.inference.coop/co-op/docs/src/branch/main/open-questions.md)
- [Gitea Actions compatibility](https://docs.gitea.com/usage/actions/comparison/)
- [Runner documentation](https://docs.gitea.com/usage/actions/runner/)
- [Package overview](https://docs.gitea.com/usage/packages/overview/)
- [Audit logging](https://docs.gitea.com/administration/audit-logging/)