Mutations printed a list row, or nothing, so a person could not tell
what changed and scripts parsed rows meant for people. Commands now get
the helpers for the gh convention:
- done and warn print "✓ Closed issue alice/x#5 (Fix login)" and
"! … is already closed" to stderr, only when stdout is a terminal and
--json is not set.
- printURL prints a created resource's URL to stdout unless --json is
set, so url=$(tea issue create …) works.
- batchDone applies a mutation to several selections like batch and
reports each success with a done line instead of a table.
- issueRef formats "alice/x#5 (title)" references.
--web now prints "Opening localhost:3001/alice/project/issues/1 in your
browser." to stderr on a terminal before the browser starts.
Signed-off-by: bircni <bircni@icloud.com>
Lists had no header, wrapped every row once a title was longer than
the terminal, and were space-padded when piped, so cut -f and awk -F'\t'
could not split them and empty cells collapsed.
terminal.Table now takes column specs and a Display. On a terminal it
prints an uppercase header, aligns columns two spaces apart and shrinks
flexible columns, widest first, to Streams.Width (the terminal, then
$COLUMNS, then 80), cutting by display width with "…". States use the
terminal's ANSI 16 colors, hex colors fall back to the 256-color palette
unless COLORTERM advertises 24-bit, and OSC 8 links appear only on the
first column, independently of color (TEA_HYPERLINKS=auto|always|never).
Piped tables are tab-separated without header, color or links, and times
are RFC3339 UTC instead of "about 2 hours ago".
terminal.View lays out single resources (title, badges, metadata, fields,
body, footer URL) and renders markdown bodies with glamour on a terminal
only (TEA_MARKDOWN=raw keeps them raw). Shared formatters cover relative
times, timestamps, sizes, durations and status icons.
In the app, writeTable and writeView are the new list and view writers:
a "Showing N of M …" context line, an empty-state message on stderr and
the next-page hint. writeList, writeItem and batch keep working and now
render through the new table: tab-separated when piped, truncated at the
widest column on a terminal, with headers for issue list and pr list.
Signed-off-by: bircni <bircni@icloud.com>
--must-change-password defaulted to true on admin user edit as well, so
changing a password with --password silently forced the user to change
it again at the next sign-in. On edit the flag now defaults to unset and
is sent only when passed; create keeps requiring a change by default.
Signed-off-by: bircni <bircni@icloud.com>
secret set, variable set, team create, webhook create and admin user
create asked a confirmation that defaults to No right after the user
typed the missing values, so pressing Enter discarded the input. They
now submit what the user entered; deletions still confirm.
Signed-off-by: bircni <bircni@icloud.com>
Gitea 28 drops a webhook's stored authorization header on every edit
that does not send it again, and never returns it, so tea cannot leave
it unchanged. The error offered --clear-authorization as an equal
alternative, which wiped credentials users still needed. It now says
the header is lost unless sent again, asks for it first, and reserves
--clear-authorization for hooks without one.
Signed-off-by: bircni <bircni@icloud.com>
Gitea replaces a team's whole unit policy on edit, so
`tea team edit 5 --unit repo.wiki=write` revoked code, issue and pull
request access. team edit now merges --unit into the current policy;
--unit-replace keeps the old replacing behavior.
Signed-off-by: bircni <bircni@icloud.com>
team delete confirmed with "delete team 3 on <host>" and deleted
whatever the ID pointed at, including an organization's owner team.
It now looks the team up first and asks to delete team "devs" (ID 5)
from acme. Deleting an owner team requires --force and, interactively,
typing the team's org/name.
Signed-off-by: bircni <bircni@icloud.com>
With stdin on a terminal, auth login --with-token read the pasted token
from the raw terminal, which echoed it in clear text without a prompt.
It now asks with a hidden "Paste an access token" prompt, and refuses
to read the terminal when prompting is disabled. Piped stdin is read as
before.
Signed-off-by: bircni <bircni@icloud.com>
setup-git appended tea's helper after the helpers Git already had, such
as osxkeychain from the system configuration. Those helpers answered
first, and after a push Git asked every helper to store tea's token, so
it ended up in the macOS Keychain where auth logout never removes it.
setup-git now writes an empty helper for the instance before tea's own,
as tea already does for its per-operation Git credentials. Add
--keep-helpers for the previous behavior.
Signed-off-by: bircni <bircni@icloud.com>
run logs and api copied server bytes straight to stdout. CI logs are
attacker-influenced through pull request workflows, so they could drive
the terminal of whoever read them. On a terminal, run logs now keep only
SGR color sequences, job names are reduced to plain text, and api drops
control characters from the response. Piped output and --output-file
stay byte-exact.
Signed-off-by: bircni <bircni@icloud.com>
pr diff copied the server's patch bytes straight to stdout, so a pull
request could change the terminal title, clear the screen or move the
cursor of whoever viewed its diff. Add terminal.SafeWriter, which
filters streamed server text like terminal.SafeText when stdout is a
terminal, and use it for pr diff. Piped output stays byte-exact, so
`tea pr diff N | git apply` keeps working.
Signed-off-by: bircni <bircni@icloud.com>
Repository discovery preferred the current branch's upstream remote,
which for a fork pull request is the pulls/<owner>/<repo> remote that
pr checkout adds, so every later command targeted the fork. pr checkout
now records the pull request number and base remote in
branch.<name>.tea-pr and branch.<name>.tea-base-remote, discovery
honors the recorded base remote, and it skips pulls/* head remotes.
Signed-off-by: bircni <bircni@icloud.com>
Cloning a fork pointed the default branch at the upstream remote, so a
plain `git push` targeted the parent repository. The branch still pulls
from upstream, which keeps tea targeting the parent, but now sets
branch.<default>.pushRemote=origin so pushes go to the fork.
Signed-off-by: bircni <bircni@icloud.com>
In a clone of a fork, repository discovery prefers the upstream remote,
so `tea repo delete --yes` deleted the parent repository. With --yes,
repo delete and repo archive now require the repository as an argument
or --repo. Interactively, repo delete asks the user to type the
repository name, and both prompts say where an inferred repository
came from.
Signed-off-by: bircni <bircni@icloud.com>
Move the repository mutation commands to repo_mutations.go and the pull request mutation commands to pull_mutations.go. No behavior change.
Signed-off-by: bircni <bircni@icloud.com>
- **switch tea to the Cobra command tree:** `internal/app` wires the packages from parts 1–4 into explicit noun/verb commands with `--repo`, `--json` / `--jq`, `--sudo` and `--debug`; `main.go` points at it. Build, release and docs tooling (`tools/cli-docs`, Makefile, goreleaser, snap, CI) and README / CONTRIBUTING are updated.
- **remove the urfave/cli command tree:** deletes `cmd/`, `modules/`, the old integration tests, contrib completion scripts and the generated `docs/CLI.md`, and drops their dependencies. This commit only deletes.
## Breaking changes
This is a breaking release. It requires Gitea 28 or newer; configuration moves to separate `config.yml` and `hosts.yml` files and requires fresh authentication, and command names, aliases, flags and output formats change. `docs/migration-1.0.md` maps every old command, flag and environment variable to its replacement.
## Issues
fixes#1118fixes#1116fixes#1115fixes#1094fixes#1091fixes#1073fixes#1052fixes#1032fixes#1023fixes#966fixes#908fixes#833fixes#831fixes#817fixes#804fixes#779fixes#770fixes#737fixes#697fixes#726fixes#677fixes#672fixes#633fixes#632fixes#560fixes#556fixes#523fixes#516fixes#510fixes#504fixes#500fixes#482fixes#406fixes#403fixes#373fixes#351fixes#344fixes#326fixes#325fixes#323fixes#246fixes#240fixes#232fixes#197fixes#172fixes#141fixes#69fixes#1110fixes#569fixes#480fixes#666fixes#670fixes#457fixes#643fixes#498fixes#490fixes#1069fixes#834fixes#602fixes#328fixes#417fixes#571fixes#1029fixes#489fixes#1050fixes#162fixes#430fixes#1087fixes#683
Reviewed-on: https://gitea.com/gitea/tea/pulls/1126
Reviewed-by: TheFox0x7 <95654+thefox0x7@noreply.gitea.com>
- `internal/services`: typed Gitea workflows built on `gitea.dev/sdk`, independent of CLI flags and terminal I/O: issues, pull requests, reviews, comments, labels, milestones, releases and assets, repositories, branches, wiki, Actions (workflows, runs, jobs, logs, artifacts, secrets, variables), organizations, teams, webhooks, notifications, SSH keys, tracked time, admin users, search and status.
- SDK types are mapped to tea's own output types, so `--json` stays a stable contract. Requests the SDK cannot express yet (e.g. pull list filters, multi-status run lists, org label archiving) go through small raw helpers, each marked `TODO(sdk)` with the missing SDK piece.
- Targets Gitea 28 or newer: no version or API-schema probing. List helpers fill pages capped by `MAX_RESPONSE_ITEMS`.
Nothing imports this package yet.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1125
Reviewed-by: TheFox0x7 <95654+thefox0x7@noreply.gitea.com>
- `internal/terminal`: streams and the prompting policy, interactive forms (issue, PR, review, merge, milestone), editor / pager / browser launching, JSON and `--jq` output.
- An aligned table renderer and a record renderer for human output; both strip control and escape characters from server-supplied text so titles and bodies cannot inject terminal sequences.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1124
Reviewed-by: TheFox0x7 <95654+thefox0x7@noreply.gitea.com>
- `internal/auth`: credentials in the OS keyring or a private file, OAuth login with token refresh, SSH HTTP-signature signers (key files with passphrase prompt, ssh-agent keys and certificates), and the Git credential helper protocol.
- `internal/git`: cancellable Git subprocesses, repository and remote discovery (tracked remote via `branch.<name>.remote`), PR checkout by full ref, AGit push, branch cleanup.
Nothing imports these packages yet.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1123
Reviewed-by: TheFox0x7 <95654+thefox0x7@noreply.gitea.com>
Part 1/5 of the tea 1.0 rewrite.
**Stack** (split from #1121; each PR targets `main` and builds, tests and lints on its own — the shipped CLI only changes in part 5):
1. #1122 Toolchain and foundation packages ← this PR
2. #1123 Credentials and Git
3. #1124 Terminal
4. #1125 Services
5. #1126 CLI wiring, docs, removal of the old tree
## Changes
- **build:** require Go 1.27; bump gofumpt and golangci-lint to releases that can read Go 1.27 export data (own commit).
- `internal/clierr`: typed errors and executable exit codes.
- `internal/version`: build version and tags.
- `internal/filelock`: moved unchanged from `modules/filelock`.
- `internal/aliases`: user-defined command aliases.
- `internal/transport`: the HTTP client the Gitea SDK runs on (part 4): token, Sudo and SSH-signature auth, retries for safe reads, connect/TLS/response-header timeouts, typed API errors that keep Gitea's message, and a redacted request log for `--debug`; plus raw requests for `tea api`, signed downloads that follow object-storage redirects, and log streaming.
- `internal/settings`: split `config.yml` / `hosts.yml` with locked transactions, plus remote URL parsing.
Nothing imports these packages yet.
Note: `flake.nix` now asks for `go_1_27`; the pinned nixpkgs in `flake.lock` predates Go 1.27 and still needs a `nix flake update nixpkgs`.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1122
Reviewed-by: TheFox0x7 <95654+thefox0x7@noreply.gitea.com>
Fixes#866
## Problem
`tea` still prompts for an SSH key passphrase for logins created with
`--ssh-agent-key` or `--ssh-agent-principal`. During `tea login add`, tea
auto-discovers a matching private key in `~/.ssh` even when the login is
configured to use the running ssh-agent. That on-disk key is stored in
`ssh_key`, so later `Login.Client()` asks for its passphrase and tells the SDK
to load the file from disk instead of signing through the agent.
## Changes
- Stop auto-discovering a private key when the login uses the ssh-agent.
- Add `Login.SSHKeyPath()` and use it for HTTPSign and git auth, so agent
logins pass an empty key path and the SDK talks to `ssh-agent`.
- Prefer SSH remotes for agent logins, matching key-file logins.
- Add unit tests for the new key-path and auto-discovery behavior.
## Testing
- `go test ./modules/config ./modules/task ./modules/git`
- `go build ./...`
---------
Co-authored-by: bircni <bircni@icloud.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1102
Reviewed-by: bircni <bircni@icloud.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Fixes#1089
## Root cause
`tea clone` initializes the command context by probing the current directory with `git rev-parse --show-toplevel`. `classifyRepoError` recognizes the "not a git repository" case by matching the English stderr text. When git emits localized errors (for example with `LANG=de_DE.UTF-8`), that match fails, and the otherwise harmless "no repo here" error is returned as fatal before cloning.
## Fix
Pin the locale of git subprocesses to `C` by overriding `LC_ALL`, `LANG`, and `LANGUAGE` in `runGitCommand`. This keeps all git output stable for parsing while leaving the parent process locale untouched.
## Tests
Added a regression test using a fake git executable that emits a German "not a repository" error unless the locale is forced to `C`, and verifies `ErrRepositoryNotExists` is returned.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1099
Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com>
## Problem
Follow-up to #1111, covering the issues side of the same hole: `tea issues create` accepts `--output` (it parses through the urfave/cli v3 ancestor-flag cascade — `issues` carries the flag via `AllDefaultFlags`, `create` never declares it) but the action never reads it. Without this fix, `tea issues create --output json | jq .url` feeds jq a markdown document.
The default output is doubly hostile to consumers: glamour renders the details as markdown (with OSC 8 hyperlinks around the URL when piped), and a second bare `fmt.Println(issue.HTMLURL)` line follows it.
## What this changes
- `task.CreateIssue` now returns the created `*gitea.Issue` instead of printing it.
- `runIssuesCreate` switches on `--output`, mirroring the detail-command precedent and the merged create-PR behavior from #1111: `--output json` emits compact lean JSON; any other value (or no flag) falls through to the previous rendering, byte-identical to before.
- Lean JSON shape: `index`, `title`, `url`, `state` — matching `createdPullJSON` in `cmd/pulls/create.go`, including its post-review compact encoding.
- The interactive path is untouched — it only triggers when zero flags are set, so `--output` can never be active there.
Example:
```
$ tea issues create --output json --title "bug: thing" | jq -r .url
https://gitea.example.com/owner/repo/issues/42
```
There is no agit-flow equivalent on issues, so no extra guard is needed — unlike the pulls side, every creation path produces an `*gitea.Issue`.
---------
Co-authored-by: Danilo Sousa <code@danilosousa.net>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1114
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: ongolk <238961+ongolk@noreply.gitea.com>
## Problem
`tea pr merge <index>` reports the same misleading error for every refusal:
```
failed to merge PR, is it still open?
```
The PR usually *is* still open — `tea pr <index>` shows it as open and lists `Conflicting files` — so the message sends users looking in the wrong direction.
## Root cause
Gitea answers an unmergeable PR with a 405 and a body naming the actual cause. The SDK's `MergePullRequest` is built on `getStatusCode`, which returns only the status code and never calls `statusCodeToErr`, so the body is discarded. tea receives `success=false, err=nil` with no server explanation to pass on, and fell back to guessing that the PR might be closed.
## Changes
- Derive the refusal reason from the pull request when a merge fails: already merged, closed, draft, or not mergeable.
- When the PR looks mergeable but was refused anyway, name the conditions tea cannot observe (required status checks, requested reviews, branch protection) instead of guessing.
- Include the PR index in the error.
- Add table-driven tests for every reason, plus the case where the follow-up PR lookup fails.
The extra API call happens only on the failure path.
Fixes#1022
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1107
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Jan Baer <jan.s.baer@googlemail.com>
## Problem
`tea pulls create` accepts `--output` (the flag parses successfully) but never reads it — the action always prints glamour-rendered markdown regardless of the requested format. That is a trap for anyone scripting the CLI: `tea pr create --output json | jq .url` quietly feeds jq a markdown document.
The current output is also hostile to URL-scraping consumers even without `--output`: glamour autolinks the bare PR URL into an OSC 8 terminal hyperlink, so piped stdout contains
```
\x1b]8;;https://host/owner/repo/pulls/33\x1b\\https://host/owner/repo/pulls/33\x1b]8;;\x1b\\
```
instead of a plain URL (repro: `tea pr create ... | cat -v`).
## Why the flag parses but does nothing
`create` itself does not declare `--output`: its flag set (`IssuePRCreateFlags`) carries no `OutputFlag`. The flag parses anyway because urfave/cli v3 resolves flags through `Command.lookupAppliedFlag`, which searches `appliedFlags` — "local flags for current command **or persistent flags from ancestors**". The parent `pulls` command carries `--output` via `AllDefaultFlags`, so the flag reaches the subcommand's parser while being absent from `create --help` — and was never consulted by the action.
## What this changes
- `task.CreatePull` now returns the created `*gitea.PullRequest` instead of printing it.
- `runPullsCreate` switches on `--output`, mirroring the existing detail-command precedent (`RunPullsDetails` in `cmd/pulls.go`): `--output json` emits a lean JSON object; any other value (or no flag at all) falls through to the previous `print.PullDetails` rendering, byte-identical to before.
- Lean JSON shape, since a freshly created PR has no reviews/comments/CI yet: `index`, `title`, `url`, `state`, `base`, `head`.
- `--agit` combined with `--output` now fails fast with an explicit error before any API call or `git push`: the agit flow creates the PR server-side via push and returns no object to print.
- The interactive path is untouched — it only triggers when zero flags are set, so `--output` can never be active there.
Example:
```
$ tea pr create --output json --title "fix: thing" | jq -r .url
https://gitea.example.com/owner/repo/pulls/33
```
---------
Co-authored-by: Danilo Sousa <code@danilosousa.net>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1111
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: ongolk <238961+ongolk@noreply.gitea.com>
Implements #1087.
Adds `tea login status [<login name>] [-o <format>]`, which verifies the stored token for one or all configured logins and reports:
- login name/URL and default status
- whether the token is valid (via `GET /api/v1/user`)
- auth method and token expiry
- whether the git credential helper is configured
Machine-readable output is available via the usual `-o` formats with fields `name`, `url`, `user`, `valid`, `auth_method`, `token_expiry`, `helper`, and `default`.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1105
Reviewed-by: bircni <bircni@icloud.com>
## Problem
`tea login add` can panic while auto-discovering SSH keys. The interactive login flow calls `regexp.FindStringSubmatch` and immediately indexes `[1]` without checking whether the regex matched. When the selected key display string does not have the expected format, the returned slice is `nil` and tea crashes with:
```
panic: runtime error: index out of range [1] with length 0
```
This is the crash reported in #527.
## Root cause
`regexp.Regexp.FindStringSubmatch` returns `nil` when the input does not match. Indexing that result with `[1]` assumes a match and causes the panic. The same unchecked pattern exists for SSH certificates and plain public keys in `modules/interact/login.go`.
## Changes
- Extract auto-discovered SSH key/certificate display parsing into `parseSSHPubkeySelection`.
- Add a `regexpSubmatch` helper that returns an error when a regex does not match, so login fails with a descriptive error instead of panicking.
- Add table-driven tests for local/agent keys, local/agent certificates, and malformed input.
Fixes#527
---------
Co-authored-by: bircni <bircni@icloud.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1100
Reviewed-by: bircni <bircni@icloud.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Closes#1095.
`tea issues create` and `tea pulls create` now resolve the description in the same way as comments: when stdin is piped and neither `--description` nor `--description-file` is given, the body is read from stdin. Both create and edit commands also accept:
```text
--description-file <path> # '-' reads stdin
```
This avoids the PowerShell 5.1 argument mangling and ANSI code page issues described in #1095.
## Changes
- Add `--description-file` to `issues create`, `issues edit`, `pulls create`, and `pulls edit`.
- Create commands fall back to piped stdin when no description flag is set.
- Add unit tests for the new body resolution.
---------
Co-authored-by: bircni <bircni@icloud.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1096
Reviewed-by: bircni <bircni@icloud.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Fixes `tea login add --oauth` hanging after the user authenticates in the
browser.
`xdg-open` (at least on Debian) runs the browser in the foreground, so it does
not exit until the browser does. `open.Run` waits for it, so tea is blocked and
doesn't get the oAuth callback from the browser.
This only happens when `xdg-open` has to start the browser. With one already
running, the new process hands off and exits immediately.
`open.Start` launches the opener and returns. The test mocks `xdg-open` with a
script that holds the foreground and fails if `openBrowser` waits on it.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1093
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: James Braid <jamesb@loreland.org>
The release pipeline uploaded artifacts to both AWS S3 (goreleaser `blobs:`) and Cloudflare R2 (custom publisher) during the migration period. The migration is done, so this removes the S3 half:
- drop the `blobs:` block from `.goreleaser.yaml`
- drop the `AWS_*` / `S3_*` env from the nightly and tag release workflows
- update the comments in `.goreleaser.yaml` and `scripts/upload-r2.sh` accordingly
Cloudflare R2 upload (including the early `--check-config` preflight step) is unchanged, and the `AWS_*` repo secrets are no longer used.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1092
Reviewed-by: bircni <bircni@icloud.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
The release pipeline uploaded artifacts to both AWS S3 (goreleaser `blobs:`) and Cloudflare R2 (custom publisher) during the migration period. The migration is done, so this removes the S3 half:
- drop the `blobs:` block from `.goreleaser.yaml`
- drop the `AWS_*` / `S3_*` env from the nightly and tag release workflows
- update the comments in `.goreleaser.yaml` and `scripts/upload-r2.sh` accordingly
Cloudflare R2 upload (including the early `--check-config` preflight step) is unchanged, and the `AWS_*` repo secrets are no longer used.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1092
Reviewed-by: bircni <bircni@icloud.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Fixes#1071
`TestRepoFromPath_Worktree` creates a throwaway temp repo and commits to it. On machines with `commit.gpgsign=true` in global git config, the commit fails with `No secret key`.
Override the global setting by setting `commit.gpgsign=false` in the temp repo's local config so the test is environment-independent.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1072
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Ross Golder <ross@golder.org>
Ports the Cloudflare R2 release mirror from [gitea.com/gitea/runner](https://gitea.com/gitea/runner) to `tea`, so release artifacts land in R2 alongside S3 for the duration of the migration away from S3.
Two commits, meant to be reviewed in order.
## 1. `ci(goreleaser): migrate release config to goreleaser v2`
A purely mechanical migration, no behaviour change intended:
- add `version: 2`
- `blobs.folder` -> `blobs.directory`
- `snapshot.name_template` -> `snapshot.version_template`
- `nightly.name_template` -> `nightly.version_template`
- `version: "~> v1"` -> `"~> v2"` in both release workflows
This is a prefactor rather than scope creep. Under goreleaser v1 the custom-publisher pipe runs *4th*, before the `release` pipe; under v2 it runs *last*. That ordering difference matters for the change below: on v1 a failed R2 upload would abort the publish after every artifact had already gone to S3 but **before** the Gitea release was created, leaving a half-finished release. On v2 the R2 mirror runs after the release exists, which matches the behaviour the runner repo already has in production.
The pre-existing `archives.format` deprecation warning is deliberately left alone; it is orthogonal to this change and the runner repo has not addressed it either.
## 2. `ci(goreleaser): mirror release artifacts to Cloudflare R2`
- **`scripts/upload-r2.sh`** — uploads one local file to one R2 object key using curl's built-in AWS SigV4 signer (R2 is S3-API compatible). Credentials are fed through `curl --config -` so they never appear in `ps` output. Also provides a `--check-config` preflight mode. This file is byte-identical to the runner repo's copy.
- **`.goreleaser.yaml`** — a `publishers:` entry mirroring the existing S3 `blobs:` upload into R2. A second `blobs:` entry is not usable here: the blob pipe authenticates from the global `AWS_*` environment and has no per-entry credentials, whereas `publishers:` supports per-entry `env:`.
- **Both release workflows** — forward the R2 secrets, plus an early `check R2 configuration` step. Custom publishers run as the very last step of goreleaser's publish pipeline, so without a preflight a missing secret would only surface after the release had been created and every artifact already uploaded to S3.
### Deviation from the runner implementation
The publisher here also sets `signature: true` in addition to `checksum: true`. `tea` has a `signs:` block that GPG-signs the checksum file, and the S3 blob pipe uploads the resulting `checksums.txt.sig`; without `signature: true` the R2 mirror would carry the artifacts and their checksums but no signature to verify them against.
The object key prefix is `tea/{{ .Version }}/...`, matching the existing S3 `directory: "tea/{{.Version}}"`.
## Required repository secrets
This PR is inert until these are configured. The preflight step will fail the release loudly if they are missing:
- `R2_ENDPOINT` — e.g. `https://<account>.r2.cloudflarestorage.com`
- `R2_BUCKET`
- `R2_ACCESS_KEY_ID`
- `R2_SECRET_ACCESS_KEY`
## Verification
- `goreleaser check` against the migrated config (with the pro-only `nightly:` block temporarily stripped, since the check ran with the OSS v2 binary): *configuration is valid*, the only deprecation being the pre-existing `archives.format`.
- A real `goreleaser build --snapshot --clean --single-target` against the v2 config: succeeded, including the `xz` and `.goreleaser.checksum.sh` post-hooks.
- `scripts/upload-r2.sh`: clean under `sh -n` and `shellcheck`; all four `--check-config` cases exercised (all vars unset, one missing, all set, wrong argument count).
- The actual upload path was not exercised end to end, since that needs live R2 credentials.
Reviewed-on: https://gitea.com/gitea/tea/pulls/1063
Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com>
The prompt shown when no login matches the current repository reads:
```
NOTE: no gitea login detected, whether falling back to login 'X'?
```
Two problems, both raised by @magistra-aria in #817:
- **"whether"** is a conjunction that needs two stated alternatives, so it doesn't parse in front of a yes/no confirm.
- **"no gitea login detected"** is misleading. The condition is that no *configured login matched this repository's remote* — not that a Gitea instance is missing. Read literally it suggests the CLI expects gitea.com specifically, which is how at least one user (me) first misread it.
Reworded to say what actually happened, for both the interactive prompt and its non-interactive counterpart:
```
NOTE: no login matched this repository. Fall back to login 'X'?
```
Strings only, no logic change.
Refs #817
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Zach Winter <contact@zachwinter.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1061
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Zach Winter <222839+zachwinter@noreply.gitea.com>
Fixes#1055.
## Root cause
`tea notifications --mine` still initialized full repository context before checking the global notification scope, so it probed the current working directory with git and could select or fail on repository-derived context even though repository data is not needed.
## Changes
- Add an InitCommand option to skip local git repository discovery when a command does not need repository context.
- Use that option for notification list and mark-as operations when `--mine` is set.
- Add a regression test that makes `git` fail if invoked and verifies `notifications --mine` still uses the global notifications API.
## Tests
- `go test ./cmd/notifications ./modules/context`
Reviewed-on: https://gitea.com/gitea/tea/pulls/1056
The `Integration Test` job is currently failing repo-wide, on unrelated PRs and on `main`:
```
curl: (7) Failed to connect to gitea port 3000 after 7 ms
```
It fails at the health check, before any Go test runs. Recent examples: #1056 (7/18), #1059, #1060, #1061.
### Cause
The health check was a single bare curl fired as soon as `setup-go` finished — there was never a readiness wait. The job has been depending on gitea binding port 3000 within however long `checkout` + `setup-go` happened to take. Timings from the job logs, container start → curl:
| run | gap | result |
|---|---|---|
| #1021 (2026-06-21) | 7.4s | pass |
| #1056 (2026-07-18) | 6.3s | fail |
| #1060 (2026-07-25) | 6.3s | fail |
Two failures a week apart with an identical gap, and curl giving up in single-digit **milliseconds** with nothing listening, points at the service still starting rather than crashing.
### What I could not determine
Two things landed in the same window and I can't separate them from outside: the service image bump 1.26.2 → 1.27.0 (d664c01) and the hosted runner fleet going v1.0.3 → v2.0.0 (visible in the log header). The service container's own stdout isn't exposed by the job log endpoint, so **"still running migrations" is inferred from timing, not observed.** Happy to be corrected by anyone who can see the container logs.
### Why this fix regardless
The missing readiness wait is the actual bug class, independent of what shifted the timing. If the service is merely slower to boot, this fixes it permanently. If it is genuinely broken, this converts a cryptic 7ms connection refusal into an explicit 60s timeout with a clear error.
Locally I verified the YAML parses and exercised both loop paths in a shell (success exits immediately; exhaustion emits `::error::` and exits 1). I can't run Gitea Actions locally, so this workflow's first real execution is the CI run on this PR — a passing `Integration Test` here is the fix demonstrating itself.
---------
Co-authored-by: Zach Winter <contact@zachwinter.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1062
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Zach Winter <222839+zachwinter@noreply.gitea.com>
Fixes https://gitea.com/gitea/tea/issues/1053
## What
tea hangs forever on Windows when it is started by something that owns a console but redirects
tea's stdio: a Windows service, a CI runner, an automation harness. Every command is affected,
`tea --version` included.
## Root cause
`modules/theme` imported `charm.land/lipgloss/v2/compat` for one struct type,
`compat.AdaptiveColor`. But compat detects the terminal background from package-level vars:
```go
var (
HasDarkBackground = lipgloss.HasDarkBackground(os.Stdin, os.Stdout)
Profile = colorprofile.Detect(os.Stdout, os.Environ())
)
```
Go initialises every package in the import graph before `main()` runs, and every file in package
`cmd` imports `modules/context`, which imports `modules/theme`. So tea queried the terminal on
every invocation, before urfave/cli had even looked at the arguments — which is why `--version`
hung.
On Windows that query opens `CONIN$`/`CONOUT$` and asks the console directly instead of giving up
when stdio is redirected, then waits for a reply that never comes. The read has a 2 second timeout,
but it does not fire, because the cancel it relies on is a no-op for that handle. Full trace in the
issue.
## Changes
- `modules/theme/theme.go` — drop the `compat` import and use `lipgloss.LightDark`, a plain
function that touches no terminal. `TeaTheme.Theme` is already handed the `isDark` it needs.
This also fixes a bug hiding in plain sight: `compat.AdaptiveColor` resolves against a
process-wide value detected at init, so the title color ignored the `isDark` argument huh passed
in. `Theme(true)` and `Theme(false)` returned the same color.
- `modules/theme/background.go` — new `HasDarkBackground()` helper that only asks the terminal when
stdin and stdout are both terminals, and otherwise assumes dark, which is the default lipgloss
itself falls back to. This is the same rule lipgloss already applies on Unix.
- `modules/interact/print.go` — `printTitleAndContent` called
`lipgloss.HasDarkBackground(os.Stdin, os.Stdout)` directly, so it hit the same wait on the
interactive paths, `tea login add` among them. It now goes through the helper.
## Why fix this in tea
The underlying bug is upstream and I have opened PRs for both halves of it: https://github.com/charmbracelet/ultraviolet/pull/138 and
https://github.com/charmbracelet/lipgloss/pull/713. But it is not fixed in any released version — lipgloss v2.0.5 is byte-identical to
v2.0.4 in the relevant files — so upgrading dependencies does not help, and tea would stay broken on
Windows until Charm cuts a release and tea bumps `go.mod`.
Separately, these changes stand on their own. tea should not query the terminal in order to print a
version string, whatever upstream does.
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Willem Kokke <mail@willem.net>
Closes#1042.
### What
`tea issue create`, `tea issue edit` and `tea pr create` all take the body via
`-d` / `--description`, but `tea comments add` and `tea comments edit` only
accepted it positionally — passing `-d` errored with
`flag provided but not defined: -d`.
This adds `-d` / `--description` to both `comments` subcommands so every
body-bearing command shares one flag.
### Behaviour / precedence
Unchanged for existing usage. Body resolution is now:
1. positional argument (kept first for back-compat),
2. `-d` / `--description`,
3. piped stdin,
4. `$EDITOR` (interactive only).
### Testing
- `go build`, `go vet ./...`, `go test -short ./cmd/... ./modules/...` all pass.
- Manually verified `tea comments add --help` / `edit --help` list the flag,
and that `-d` resolves the body (reaches the API, no parse error, no editor
prompt, no stdin block).
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1043
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Brien Coffield <coffbr01@gmail.com>
Co-committed-by: Brien Coffield <coffbr01@gmail.com>
bircni
