~ knotless Search/
↑↓ move↵ open⇧↵ all results

grain.social/grain

photography-focused photo sharing platform

grain.social
1 collaborator
0
2

Checks run on pulls into feature branches

Merged chadtmiller.com asked to merge into feature/rust from grain.social/grain:ci/feature-branches

Only what this pull adds. It is built on grain runs on a Rust server modelled on knotless, without hatk.

.knotless/workflows/check.yml+1−1
@@ -5,7 +5,7 @@ image: node:25-slim
runners: [runner.knotless.dev]
on:
push: { refs: [refs/heads/main] }
pull: { base: [refs/heads/main] }
pull: { base: [refs/heads/main, refs/heads/feature/*] }
cache: [node_modules]
steps:
- name: packages
.knotless/workflows/test.yml+1−1
@@ -6,7 +6,7 @@ image: node:25-slim
runners: [runner.knotless.dev]
on:
push: { refs: [refs/heads/main] }
pull: { base: [refs/heads/main] }
pull: { base: [refs/heads/main, refs/heads/feature/*] }
cache: [node_modules]
steps:
- name: packages
AGENTS.md+36−0
@@ -4,6 +4,42 @@ This is an AT Protocol application built with [hatk](https://github.com/hatk-dev
Read the project's lexicons in `lexicons/` to understand the data model.
Types are generated from lexicons into `hatk.generated.ts` — never edit this file directly.
## Landing a change
grain is kept on knotless, at `knotless://grain.social/grain`. GitHub and
Tangled are mirrors that `mirror.yml` fast-forwards from main; nothing is
opened or pushed there.
- Build and test on the runner, not on this machine: several agents
building here at once have brought it down. Open the pull early, push to
its branch as you go, and read what its checks say (or use the `checks`
tool over MCP):
```sh
knotless checks knotless://grain.social/grain --pull <uri> --wait <secs> --log
```
Run something here only for a loop the runner is too slow for, such as
one test being fixed, in one checkout at a time.
- A pull's title and body follow `.knotless/pull.md`, which
`knotless template knotless://grain.social/grain pull` prints.
- review.knotless.dev reviews every open pull by the owner or a
collaborator, at each head pushed. Read its review with `knotless show`
and answer it by pushing, or in a comment saying why not.
- Nothing lands on main until the owner says so for that pull: main
deploys to production once its checks pass. Open the pull and stop.
- Work that should not reach main yet goes on a feature branch,
`feature/<name>`, cut from main. Its parts are pulls into it, which
`check` and `test` run on as they do on pulls into main, and which are
reviewed the same way. Nothing deploys from a feature branch. Keep one
pull open from it into main, unqueued, as the check that the whole of it
still passes there, and merge main into the feature branch as main
moves.
`feature/rust` holds the move off hatk onto a Rust server modelled on
knotless: one pull into it per step of the plan.
## Project structure
| Directory | Purpose |