fisher
3a6fafb5c7
Replaces the per-project deploy scripts and self-contained webhook receivers with one manifest-driven implementation that lives outside the application repositories and can be updated independently of them. First targets: domaindingo test and prod on s5.
58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
# Gitea workflow
|
|
|
|
## Branch flow
|
|
|
|
`main` → `test` → `dev` → feature branches.
|
|
|
|
`test` is the default branch, protected, merge-only.
|
|
|
|
For a brand-new empty repo: create `test` from `main`, then `dev` from `test`.
|
|
|
|
## Posting with `tea`
|
|
|
|
When posting to Gitea with `tea` (issues, comments, PRs):
|
|
|
|
- Run it in the **foreground**.
|
|
- **Use the right body argument** — there is no `--body` flag and no
|
|
read-from-file option:
|
|
- `tea issues create` / `tea pulls create`: body is `--description` / `-d`
|
|
- `tea comment <index> [<body>]`: body is a **positional** argument (no flag)
|
|
- **Never put `\n` escape sequences in the body.** `tea` stores the string
|
|
verbatim — it does not interpret escapes, so any `\n` you pass appears
|
|
*literally* in the posted text. The body must already contain real newlines:
|
|
write it to a file (the Write tool, or `printf` — never `echo "...\n..."`),
|
|
then pass it by command substitution, e.g. `-d "$(cat body.md)"` or
|
|
`tea comment 42 "$(cat body.md)"`. Inline heredocs and `\n`-laden argument
|
|
strings are what cause the literal `\n`.
|
|
- **Confirm it actually posted** — check the exit code *and* re-read the created
|
|
item; verify the body renders with real line breaks, not literal `\n`. `tea`
|
|
can fail silently.
|
|
- **Write subcommands hang on inherited stdin.** Even with the body passed as an
|
|
argument, `tea` (`comment`, `issues edit`, `issues close`, `pulls create`, …)
|
|
reads stdin; in a non-TTY shell the inherited stdin never sends EOF, so the
|
|
command blocks until it is killed. **Fix: redirect stdin — append `</dev/null`**
|
|
to every `tea` *write* subcommand (e.g. `tea comment 42 "$(cat body.md)"
|
|
</dev/null`). Plain reads are unaffected.
|
|
- `--repo` is optional inside the repo — it is not the fix for a silent failure.
|
|
|
|
## Reading and editing with `tea` (prefer `tea` over the API)
|
|
|
|
`tea` covers every issue/PR operation this workflow needs — there is **no
|
|
capability gap** versus the raw Gitea API, so reach for `tea` first and drop to
|
|
`curl` on `/api/v1/...` only if a genuinely new gap appears. Recent findings that
|
|
correct earlier assumptions:
|
|
|
|
- **Show a full issue/PR body:** `tea issue <n>` (note: `tea issues view <n>`
|
|
does *not* print the full body).
|
|
- **Show comments:** `tea issue <n> --comments`. Comments are hidden by default,
|
|
but this flag renders them — you do **not** need the API to read comments.
|
|
- **Edit an existing issue body:** `tea issues edit <n> -d "$(cat body.md)"
|
|
</dev/null`. `-d`/`--description` does a **full-body replace**. This subcommand
|
|
exists — earlier notes claiming `tea` could not edit bodies (and that the API
|
|
was required) were wrong. `tea issues edit` also sets title/labels/milestone/
|
|
assignees.
|
|
- The `curl` fallback has its own friction (the shell's proxy can mangle piped
|
|
`curl` output — write to a file then parse; comment POSTs need a
|
|
`{"body": "..."}` wrapper) and offers no capability upside, so it is a last
|
|
resort, not the default.
|