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.
2.9 KiB
2.9 KiB
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
--bodyflag and no read-from-file option:tea issues create/tea pulls create: body is--description/-dtea comment <index> [<body>]: body is a positional argument (no flag)
- Never put
\nescape sequences in the body.teastores the string verbatim — it does not interpret escapes, so any\nyou pass appears literally in the posted text. The body must already contain real newlines: write it to a file (the Write tool, orprintf— neverecho "...\n..."), then pass it by command substitution, e.g.-d "$(cat body.md)"ortea 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.teacan 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/nullto everyteawrite subcommand (e.g.tea comment 42 "$(cat body.md)" </dev/null). Plain reads are unaffected. --repois 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/--descriptiondoes a full-body replace. This subcommand exists — earlier notes claimingteacould not edit bodies (and that the API was required) were wrong.tea issues editalso sets title/labels/milestone/ assignees. - The
curlfallback has its own friction (the shell's proxy can mangle pipedcurloutput — 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.