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>
When --redirect-url is omitted, the local callback listener binds to a
free port and opts.RedirectURL is rewritten with it. oauth2Config.RedirectURL
was never updated, so Exchange() sent the stale http://127.0.0.1:0 while
the authorize step had sent the real port. RFC-6749-compliant servers
(Gitea >= #37704, current Forgejo) reject the mismatch.
Propagate the resolved URL back into oauth2Config before Exchange. Add a
regression test using httptest that drives the flow end-to-end and asserts
the redirect_uri values match.
---------
Co-authored-by: dbankmann <204984+dbankmann@users.noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1019
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Daniel Bankmann <204984+dbankmann@noreply.gitea.com>
Co-committed-by: Daniel Bankmann <204984+dbankmann@noreply.gitea.com>
## Why
Today `tea comment` can only *add* a comment. Editing or deleting requires falling back to `tea api`. This came up while I was iterating on PRs in this same repo earlier today and had to correct a couple of comments by hand. Every comparable forge CLI (gh, glab, etc.) exposes these operations as first-class commands.
## What
Restructures `tea comment` from a single-action command into a parent with four subcommands. The parent's default action remains the existing "add" behavior, so the historical shorthand keeps working.
| Command | Purpose |
|---|---|
| `tea comment add <idx> [<body>]` | Add a comment (explicit subcommand) |
| `tea comment list <idx>` | Tabular listing including comment IDs |
| `tea comment edit <id> [<body>]` | Replace the body of one comment |
| `tea comment delete <id> [<id>...]` | Delete one or more comments |
| `tea comment <idx> [<body>]` | Unchanged — still routes to `add` |
The `list` command exists specifically so users can discover the IDs that `edit` and `delete` accept.
## Backward compatibility
The whole point of routing the parent's default `Action` through `add` is to preserve every existing invocation. `tea comment 1 "body"` still does what it did before. No flag or arg names change.
## Input forms (for add and edit)
Same pattern as the original `tea comment`:
1. Positional body (`tea comment edit <id> "new body"`) — wins if present.
2. Piped stdin if no positional body is given.
3. External `$EDITOR` (pre-populated with the current body, on `edit`) if neither.
This matches the stdin-handling fix in #1011 — positional body wins over a non-TTY stdin so the command doesn't hang in CI/subshells.
## Verification
All four subcommands were exercised live against `https://gitea.com/dinsmoor/tea-testing` issue #1. The test artifacts and a summary log are visible on that issue right now. Specifically:
- The annotated summary comment lists every operation tested and the comment IDs each one acted on.
- Comments 1197162 (legacy add), 1197163 (subcommand add, later edited), 1197164 (stdin add) are still there to be inspected.
- Comment 1197166 was created and then deleted; its absence from `tea comment list` output is evidence that delete works.
## New files
- `cmd/comments/add.go` — extracted from the old `cmd/comment.go`
- `cmd/comments/list.go`
- `cmd/comments/edit.go`
- `cmd/comments/delete.go`
- `modules/print/comment.go` — adds `CommentsList` helper for the tabular output
`cmd/comment.go` is rewritten as a thin parent that wires these together.
## Open questions for the reviewer
- **Naming**: should the top-level command be `comments` (plural) or stay `comment` (singular)? I kept it singular with `comments` as an alias to match the existing user-visible name.
- **Delete confirmation**: I did not add a confirmation prompt — `delete` just deletes. Some projects gate this behind `--yes` / interactive `[y/N]`. I'd rather follow whatever convention the maintainers prefer.
- **Output format on list**: currently uses the existing `print.tableWithHeader` helper, matching `tea organizations list` etc. Other tea listings support `--output json` / `--output csv` via the shared `--output` flag, which works here automatically through the same helper.
---
This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.
*pull request created by Tyler's lovingly wrangled demon machine <3*
Reviewed-on: https://gitea.com/gitea/tea/pulls/1015
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: dinsmoor <204368+dinsmoor@noreply.gitea.com>
Co-committed-by: dinsmoor <204368+dinsmoor@noreply.gitea.com>
Closes#979. An alternative to the approach in #980 — this one is purely client-side title-mangling, no SDK changes needed.
Gitea already treats any PR with a `WIP:` or `[WIP]` title prefix (case-insensitive) as a draft. This patch wires three flags around that behavior:
- `tea pulls create --draft` — prepend `WIP: ` to the title at creation time
- `tea pulls edit --draft <idx>` — add `WIP: ` to an existing PR's title
- `tea pulls edit --ready <idx>` — strip any recognized draft prefix
All three are idempotent. `--draft` and `--ready` on edit are mutually exclusive. If the user also passes `--title` on edit, the toggle applies to the supplied title; otherwise the current title is fetched from the server first.
Why this approach over a server-payload-based one: Gitea's draft state is *defined* as the title-prefix convention (see the Gitea source for `HasWIPPrefix`). Modeling it server-side would either duplicate or fight that. A small string helper covers it without needing the SDK to add a `Draft` field.
Verified against `gitea.com` (1.26.0+dev) with a throwaway repo:
- create with `--draft` → server reports `draft: true` ✓
- `edit --ready` strips → `draft: false` ✓
- `edit --draft` adds back → `draft: true` ✓
- second `edit --draft` is idempotent ✓
- `edit --draft --ready` errors ✓
Unit tests for the prefix detection live in `modules/utils/draft_test.go`.
---
This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step. Reproduction, design decisions, and the choice not to follow #980's payload approach were mine — happy to discuss any of it.
*pull request created by Tyler's lovingly wrangled demon machine <3*
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1008
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
Closes#1009.
## The standard fork-flow
The textbook workflow for opening a PR with any git CLI (gh, glab, hub, tea, etc.) is:
1. Fork `upstream/repo` on the server.
2. Clone the fork locally; add `upstream` as a second remote.
3. Branch off, commit, push the branch to your fork.
4. Tell the tool: "open a PR on `upstream/repo`, source is `fork:branch`".
In tea that's:
```
tea pulls create --repo upstream/repo --head fork:branch --base main
```
This is the flow tea supported before #850 and the flow this repo's own contribution model assumes.
## What broke
#850 ("Enable git worktree support and improve pr create error handling", Nov 2025) correctly addressed worktree detection by adding `LocalRepo: true` to `runPullsCreate`'s `CtxRequirement`. But that requirement is checked before `--repo` is interpreted, and a slug-style `--repo gitea/tea` doesn't satisfy `LocalRepo` — only a path does.
Result: the standard fork-flow invocation above started failing with:
```
Error: local repository required: execute from a repo dir, or specify a path with --repo
```
— which is misleading, because the user IS in a repo dir and `--repo` IS set.
## The fix
Only require `LocalRepo` when the command genuinely needs the working tree:
- **Interactive mode** (no flags) — uses tree info for prompts.
- **`--head` omitted** — defaults head from the current branch.
Otherwise the command runs with just `RemoteRepo`, and `task.CreatePull` takes the explicit `--repo` and `--head` as given. The #850 worktree fix is preserved for the in-tree path.
## Behavior table
| Invocation | Before | After |
|---|---|---|
| `tea pulls create` (interactive) | works | works (unchanged) |
| `tea pulls create --head my-branch --base main` (in-tree, same repo) | works | works (unchanged) |
| `tea pulls create --repo upstream/repo --head fork:branch --base main` (fork-flow) | **fails with misleading error** | **works** |
| `tea pulls create --repo upstream/repo --base main` (no `--head`, no working tree) | fails | still fails with the same error (correctly — head can't be defaulted without a working tree or explicit flag) |
## Verification
Smoke-tested by opening a PR from `/tmp` (deliberately not a git repo):
```
cd /tmp
tea-dev pulls create --login gitea.com --repo dinsmoor/tea-testing \
--head dinsmoor:xfork-smoke --base main \
--title "xfork smoke test" --description "..."
→ https://gitea.com/dinsmoor/tea-testing/pulls/4
```
And in fact, **this very PR was opened using the patched binary** invoked from `/tmp`, since the released `tea` still has the bug.
---
This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.
*pull request created by Tyler's lovingly wrangled demon machine <3*
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1010
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
## The bug
`tea comment <idx> "body"` hangs forever in any non-TTY context — CI pipelines, subshells, agent harnesses, scripts — unless the user explicitly redirects stdin with `< /dev/null`.
### Reproduction (released `tea` 0.14.1)
```
# Plain positional body — hangs forever
$ tea comment --repo owner/repo 1 "body text"
# Heredoc body — hangs forever
$ tea comment --repo owner/repo 1 "$(cat <<'EOM'
body text
EOM
)"
# Workaround that works (but shouldn't be necessary)
$ tea comment --repo owner/repo 1 "body text" < /dev/null
```
Verified on `gitea.com` (server 1.26.0+dev) with `tea 0.14.1`. Both hanging cases hit a 30s timeout in testing; in normal shell use they hang indefinitely.
## Root cause
`cmd/comment.go:58-65`:
```go
body := strings.Join(ctx.Args().Tail(), " ")
if interact.IsStdinPiped() {
if bodyStdin, err := io.ReadAll(ctx.Reader); err != nil {
return err
} else if len(bodyStdin) != 0 {
body = strings.Join([]string{body, string(bodyStdin)}, "\n\n")
}
}
```
`interact.IsStdinPiped()` is implemented as `!term.IsTerminal(os.Stdin)` — true for *any* non-TTY stdin, not just for piped data. When tea enters this branch in a subshell where stdin is open but no producer ever writes to it (the typical case for shell scripts and automation), `io.ReadAll` blocks waiting for an EOF that never arrives.
## Fix
Only consume stdin when the user did **not** supply a positional body. If they passed a body via args, that's their content — ignore stdin entirely.
```go
if len(body) == 0 && interact.IsStdinPiped() {
// ... read stdin ...
body = string(bodyStdin)
}
```
## Behavior matrix
| Invocation | Before | After |
|---|---|---|
| `tea comment <idx> "body"` (TTY) | works | works |
| `tea comment <idx> "body"` (non-TTY, no redirect) | **hangs forever** | **works** |
| `tea comment <idx> "body" < /dev/null` | works | works |
| `echo body \| tea comment <idx>` | works | works |
| `tea comment <idx> "prefix"` + piped stdin | "prefix" + stdin concatenated | positional body wins, stdin ignored |
| `tea comment <idx>` (TTY, no body, no pipe) | opens editor | opens editor |
The one behavior change is the prefix-plus-stdin case (5th row). I couldn't find anyone relying on that pattern and it wasn't documented; defaulting to "positional body wins" matches the principle of least surprise.
## Verification
Confirmed each row against `dinsmoor/tea-testing` issue #1 on `gitea.com` with the patched binary. Previously-hanging invocations now post in <0.5s. Piped-stdin path unchanged.
---
This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.
*pull request created by Tyler's lovingly wrangled demon machine <3*
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1011
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
Closes#1013.
## Background
While trying to use `tea` from a non-interactive context I hit a friction point: after `tea login add` succeeded, plain `git push` over HTTPS still prompted for credentials. I filed #1013 as a feature request to add credential helper integration — then found, on reading the source, that the integration **already exists**:
- `tea login add` accepts `--helper` (alias `-j`), which calls `task.SetupHelper` to register a credential helper in `~/.gitconfig`.
- `tea login helper get` correctly implements git's credential protocol, reading the request from stdin and returning `protocol`/`host`/`username`/`password` lines.
- `tea login helper setup` does the same for every configured login.
I verified end-to-end that this works as advertised: after `tea login helper setup`, an HTTPS `git push` against a configured Gitea host authenticates silently using the stored token, no prompts, with `GIT_TERMINAL_PROMPT=0` set as a safety check.
So the feature is fine. The problem is that nobody can find it:
| Surface | Before | Issue |
|---|---|---|
| Flag name on `tea login add` | `--helper` (alias `-j`) | Generic; nothing tying it to git or credentials |
| Flag usage text | `"Add helper"` | Says nothing |
| `tea login helper` command | `Hidden: true` | Not in `tea login --help` |
| `tea login helper` usage | `"Git helper"` | Says nothing |
| `tea login helper` description | `"Git helper"` | Same string again |
| `store/erase` subcommand description | `"Command drops"` | Sentence fragment, no meaning |
| `setup` subcommand description | `"Setup helper to tea authenticate"` | Awkward, doesn't explain what it touches |
| `get` subcommand description | `"Get token to auth"` | Doesn't mention git, stdin, or the credential protocol |
| Mention in `tea login add --help` | None | Feature is invisible |
## What this patch does
Purely cosmetic / documentation changes — **no behavior changes**:
1. Renames `--helper` to `--git-credentials`, keeping `--helper` and `-j` as aliases so existing scripts and muscle memory keep working.
2. Removes `Hidden: true` from `tea login helper` so it appears in `tea login --help`.
3. Rewrites every placeholder `Usage` and `Description` string in the helper command tree to describe what the thing actually does.
4. Expands the top-level `Description` of `tea login add` to mention the option and explain what it does.
5. Prints a one-line hint after a successful non-helper login: `Tip: pass --git-credentials (or run 'tea login helper setup') to authenticate 'git push' and 'git clone' over HTTPS with this token.`
The credential helper protocol implementation, `SetupHelper`'s gitconfig writes, and the `get`/`store`/`setup` action functions are all unchanged.
## Help output after the patch
```
$ tea login --help
COMMANDS:
...
helper, git-credential Act as a git credential helper for stored Gitea logins
...
$ tea login helper --help
NAME:
tea logins helper - Act as a git credential helper for stored Gitea logins
DESCRIPTION:
Speaks git's credential helper protocol so that HTTPS push and clone
operations against your configured Gitea instances authenticate silently
using the tokens tea already stores.
Typical use is automatic: 'tea login add --git-credentials' (or 'tea login
helper setup' for existing logins) registers '!tea login helper' as a
credential helper in ~/.gitconfig. Git then invokes the 'get' subcommand
when it needs credentials for a configured host.
COMMANDS:
store, erase No-op (git credential protocol store/erase)
setup Register tea as a git credential helper for every configured login
get Return the stored token for a URL (git credential protocol)
```
## Open questions for the reviewer
A few choices in here that are subjective — happy to change any of them:
- **Flag name**: `--git-credentials` was the first clear name I tried. `--credential-helper` and `--git-helper` are also reasonable. Or keep `--helper` as canonical and just fix its usage text.
- **Canonical subcommand name**: I kept `helper` as canonical with `git-credential` as alias, matching what was already there. Could flip this — `gh` uses `gh auth git-credential` as canonical with no `helper` form.
- **Should `--git-credentials` default to true?** Most users probably want it on; the current opt-in design surprises them. But flipping the default is a behavior change so I left it alone here.
- **Should the hint be silenced by an env var or a config flag?** I left it always-on for the people who need to see it; can gate it if it bothers automation users.
- **Teardown on `tea login delete`** would parallel the setup behavior, but is genuinely a separate change. Not in this PR.
---
This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.
*pull request created by Tyler's lovingly wrangled demon machine <3*
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/1014
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
## The bug
`tea pulls create` and `tea pulls edit` print `• **Conflicting files**` for any open PR that the server reports as `mergeable: false`. But Gitea's API returns `mergeable: false` for **draft PRs by design** — drafts cannot be merged regardless of conflict state. The current code conflates "not mergeable for any reason" with "has file conflicts."
### Reproduction (gitea.com 1.26.0+dev)
```
$ tea pulls create --base main --head my-branch --title "WIP: clean diff" --description "..."
# #N WIP: clean diff (open)
...
• **Conflicting files** ← misleading
• Maintainers are allowed to edit
```
The PR has no actual conflicts. The web UI shows it as draft + cleanly diffable. `tea pulls edit --title "WIP: ..."` shows the same misleading line.
API confirms the root signal:
```
$ curl /api/v1/repos/owner/repo/pulls/N
{ "draft": true, "mergeable": false, ... }
```
Strip the WIP prefix, and `mergeable` flips back to `true`. So `mergeable=false` here means "blocked because draft," not "conflicts."
## Fix
Distinguish the two reasons in `modules/print/pull.go`:
```go
switch {
case pr.Mergeable:
out += "- No Conflicts\n"
case pr.Draft:
out += "- Draft (not mergeable until marked ready)\n"
default:
out += "- **Conflicting files**\n"
}
```
Real conflicts still fall through to the existing "Conflicting files" message.
## Behavior matrix
| PR state | API `mergeable` | Before | After |
|---|---|---|---|
| Open, clean, ready | true | No Conflicts | No Conflicts |
| Open, draft, clean | false | **Conflicting files** (wrong) | **Draft (not mergeable until marked ready)** |
| Open, conflicting | false | Conflicting files | Conflicting files |
| Closed/merged | — | (no line shown) | (no line shown) |
## Verification
Against `dinsmoor/tea-testing` PR #6 on gitea.com:
- Set title to `WIP: ...` → API `mergeable=false`, `draft=true` → tea prints `Draft (not mergeable until marked ready)` ✓
- Strip WIP → API `mergeable=true`, `draft=false` → tea prints `No Conflicts` ✓
---
This patch was authored interactively with an AI assistant, driven and reviewed by a human (Tyler / @dinsmoor) every step.
*pull request created by Tyler's lovingly wrangled demon machine <3*
Reviewed-on: https://gitea.com/gitea/tea/pulls/1012
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tyler <tyler@dinsmoor.us>
Co-committed-by: Tyler <tyler@dinsmoor.us>
## Summary
Add first-class `tea wiki` commands backed by the existing Gitea wiki API and SDK support.
## What this adds
- `tea wiki list`
- `tea wiki view <page>`
- `tea wiki revisions <page>`
- `tea wiki create`
- `tea wiki edit <page>`
- `tea wiki delete <page>`
## Implementation details
- registers a new top-level `wiki` entity command
- keeps command logic under `cmd/wiki/`
- adds wiki-specific renderers in `modules/print/wiki.go`
- adds wiki task helpers in `modules/task/wiki.go`
- reuses existing repo/login/output/pagination patterns used elsewhere in `tea`
- base64-encodes wiki content for create/edit API calls
- requires explicit `--confirm` for delete
- preserves the current page title during edit when `--title` is omitted
## Test coverage
The PR is intentionally split into two commits:
1. `feat: add wiki CLI commands`
2. `test: add wiki integration coverage`
Validation performed:
- focused command, task, and print tests for the new wiki functionality
- integration coverage for the wiki command lifecycle
- `make lint`
- `make fmt-check`
- `make docs-check`
- `make build`
- upstream PR CI passed:
- `check-and-test / Integration Test`
- `check-and-test / Lint Build And Unit Coverage`
## Motivation
This makes `tea` a better interface for both human and agent-driven workflows by exposing wiki operations as stable first-class CLI commands instead of requiring ad-hoc API calls or custom wrappers.
---
Generated by Hermes Agent with GPT-5.4
---------
Co-authored-by: nitro <nitro@nitroui-Macmini.local>
Reviewed-on: https://gitea.com/gitea/tea/pulls/998
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: kuil09 <202447+kuil09@noreply.gitea.com>
Co-committed-by: kuil09 <202447+kuil09@noreply.gitea.com>
Bumping gitea SDK to version v0.25.0
Currently there is an issue when users try to use SSH to authenticate to a gitea server. The issue is already reported here #983
The problem was that `*gitea.HTTPSign` embeds `ssh.Signer` (not `ssh.AlgorithmSigner`).
`httpsig v1.2.4` type-asserts the signer to `ssh.AlgorithmSigner` for RSA keys and panics because `*HTTPSign` doesn't expose `SignWithAlgorithm`.
Fix: SDK v0.25.0 adds `SignWithAlgorithm` to `HTTPSign`, satisfying `ssh.AlgorithmSigner`.
Reviewed-on: https://gitea.com/gitea/tea/pulls/984
Reviewed-by: techknowlogick <9+techknowlogick@noreply.gitea.com>
Co-authored-by: Carlos Grillet <carlosbeta5000@gmail.com>
Co-committed-by: Carlos Grillet <carlosbeta5000@gmail.com>
## What this PR does
`tea issues list --assignee USERNAME` currently returns every issue regardless of the assignee value — even nonexistent users return a full unfiltered list. Discovered against **tea v0.14.0** (with go-sdk v0.24.1) and reproduced on current `master` (commit `dd81b33`). This PR fixes that.
## Root cause
Two distinct bugs on the same flag, both in `cmd/issues/list.go`:
1. **Per-repo path** (`tea issues list --repo OWNER/REPO --assignee USER`): the code reads `ctx.String("assigned-to")` for `AssignedBy`, but the flag is defined as `--assignee` in `cmd/flags/issue_pr.go:66`. The lookup always returns `""`, so the SDK omits the `assigned_by` query parameter and the API returns everything.
2. **Global path** (`tea issues list --assignee USER`, no `--repo`): this hits `/repos/issues/search`, which silently ignores `assigned_by`. Even after fix#1 the no-repo form would still return unfiltered results. Verified directly:
- `GET /repos/issues/search?assigned_by=USER&owner=ORG&state=open` → all open issues
- `GET /repos/issues/search?assigned=true&owner=ORG&state=open` → only the issues assigned to the authenticated user
The endpoint only supports `assigned=true` (boolean self-filter), not arbitrary-user filtering, and `ListIssueOption` doesn't expose that field. Rather than misleading the caller, the no-repo path now returns a clear error.
## Changes
Both changes are in `cmd/issues/list.go`:
1. Read `ctx.String("assignee")` instead of the non-existent flag name `"assigned-to"` (lines 80 and 97).
2. In the no-`--repo` branch, return `errors.New("--assignee requires --repo (...)")` when the flag is set.
`cmd/pulls/list.go` does not expose an assignee filter, so it's unaffected. The `--author` mapping (`CreatedBy ← ctx.String("author")`) was already correct and is the model the fix follows.
## Manual verification
Tested against a local Gitea instance with three open issues (only one assigned to the test user):
| Command | Before | After |
|---|---|---|
| `tea issues list --repo X --assignee me` | all 3 | only the 1 assigned ✓ |
| `tea issues list --repo X --assignee nonexistent` | all 3 | `Error: not found` ✓ |
| `tea issues list --repo X --author me` | only the 1 (control) | unchanged ✓ |
| `tea issues list --assignee me` (no `--repo`) | all 3 (silent) | clear error ✓ |
| `tea issues list` (no flags) | all 3 | unchanged ✓ |
---------
Co-authored-by: claude_1 <claude_1@bot.gqx.lol>
Reviewed-on: https://gitea.com/gitea/tea/pulls/971
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Oleksii Zaremskyi <grossqx@gmail.com>
Co-committed-by: Oleksii Zaremskyi <grossqx@gmail.com>
## Summary
\`Page: -1\` in the Gitea SDK calls \`setDefaults()\` which sets both \`Page=0\` and \`PageSize=0\`, resulting in \`?page=0&limit=0\` being sent to the server. The server interprets \`limit=0\` as "use server default" (typically 30 items via \`DEFAULT_PAGING_NUM\`), not "return everything". Any resource beyond the first page of results was silently invisible.
This affected 8 call sites, with the most user-visible impact being \`tea issues edit --add-labels\` and \`tea pulls edit --add-labels\` silently failing to apply labels on repositories with more than ~30 labels.
## Affected call sites
| File | API call | User-visible impact |
|---|---|---|
| \`modules/task/labels.go\` | \`ListRepoLabels\` | \`issues/pulls edit --add-labels\` fails silently |
| \`modules/interact/issue_create.go\` | \`ListRepoLabels\` | interactive label picker missing labels |
| \`modules/task/pull_review_comment.go\` | \`ListPullReviews\` | review comments truncated |
| \`modules/task/login_ssh.go\` | \`ListMyPublicKeys\` | SSH key auto-detection fails |
| \`modules/task/login_create.go\` | \`ListAccessTokens\` | token name deduplication misses existing tokens |
| \`cmd/pulls.go\` | \`ListPullReviews\` | PR detail view missing reviews |
| \`cmd/releases/utils.go\` | \`ListReleases\` | tag lookup fails on repos with many releases |
| \`cmd/attachments/delete.go\` | \`ListReleaseAttachments\` | attachment deletion fails when many attachments exist |
## Fix
Each call site is replaced with an explicit pagination loop that follows \`resp.NextPage\` until all pages are exhausted.
Reviewed-on: https://gitea.com/gitea/tea/pulls/967
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Alain Thiffault <athiffau@effectivemomentum.com>
Co-committed-by: Alain Thiffault <athiffau@effectivemomentum.com>
Treat explicit --repo slugs as remote targets so commands do not probe
the current worktree. This avoids SHA256 repository failures when local
git autodetection is unnecessary.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/960
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Matěj Cepl <mcepl@cepl.eu>
Co-committed-by: Matěj Cepl <mcepl@cepl.eu>
## Summary
- Add `"ci"` as a new selectable field for `tea pr list --fields`, allowing users to see CI status across multiple PRs at a glance
- Fetch CI status via `GetCombinedStatus` API **only when the `ci` field is explicitly requested** via `--fields`, avoiding unnecessary API calls in default usage
- Improve CI status display in both detail and list views:
- **Detail view** (`tea pr <index>`): show each CI check with symbol, context name, description, and clickable link to CI run
- **List view** (`tea pr list --fields ci`): show symbol + context name per CI check (e.g., `✓ lint, ⏳ build, ❌ test`)
- **Machine-readable output**: return raw state string (e.g., `success`, `pending`)
- Replace pending CI symbol from `⭮` to `⏳` for better readability
- Extract `formatCIStatus` helper and reuse it in `PullDetails` to reduce code duplication
- Add comprehensive tests for CI status formatting and PR list integration
## Detail View Example
```
- CI:
- ✓ [**lint**](https://ci.example.com/lint): Lint passed
- ⏳ [**build**](https://ci.example.com/build): Build is running
- ❌ [**test**](https://ci.example.com/test): 3 tests failed
```
## List View Example
```
INDEX TITLE STATE CI
123 Fix bug open ✓ lint, ⏳ build, ❌ test
```
## Usage
```bash
# Show CI status column in list
tea pr list --fields index,title,state,ci
# Default output is unchanged (no CI column, no extra API calls)
tea pr list
```
## Files Changed
- `cmd/pulls/list.go` — conditionally fetch CI status per PR when `ci` field is selected
- `modules/print/pull.go` — add `ci` field, `formatCIStatus` helper, improve detail/list CI display
- `modules/print/pull_test.go` — comprehensive tests for CI status formatting
## Test plan
- [x] `go build ./...` passes
- [x] `go test ./...` passes (11 new tests)
- [x] `tea pr list` — default output unchanged, no extra API calls
- [x] `tea pr list --fields index,title,state,ci` — CI column with context names
- [x] `tea pr <index>` — CI section shows each check with name, description, and link
- [x] `tea pr list --fields ci -o csv` — machine-readable output shows raw state strings
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: https://gitea.com/gitea/tea/pulls/956
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-committed-by: Bo-Yi Wu <appleboy.tw@gmail.com>
## Summary
- Upgrade all Go module dependencies to their latest versions
- Includes updates to charm.land, golang.org/x, goldmark, go-crypto, and other indirect dependencies
- Project builds cleanly with all updates
## Test plan
- [x] `go build ./...` passes
- [x] CI pipeline passes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Reviewed-on: https://gitea.com/gitea/tea/pulls/955
Co-authored-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-committed-by: Bo-Yi Wu <appleboy.tw@gmail.com>
## Summary
- Extract duplicate \`getReleaseByTag\` into shared \`cmd/releases/utils.go\`
- Replace \`log.Fatal\` calls with proper error returns in config and login commands; \`GetLoginByToken\`/\`GetLoginsByHost\`/\`GetLoginByHost\` now return errors
- Remove dead \`portChan\` channel in \`modules/auth/oauth.go\`
- Fix YAML integer detection to use \`strconv.ParseInt\` (correctly handles negatives and large ints)
- Fix \`path.go\` error handling to use \`errors.As\` + \`syscall.ENOTDIR\` instead of string comparison
- Extract repeated credential helper key into local variable in \`SetupHelper\`
- Use existing \`isRemoteDeleted()\` in \`pull_clean.go\` instead of duplicating the logic
- Fix ~30 error message casing violations to follow Go conventions
- Use \`fmt.Errorf\` consistently instead of string concatenation in \`generic.go\`
Reviewed-on: https://gitea.com/gitea/tea/pulls/947
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-by: Bo-Yi Wu (吳柏毅) <appleboy.tw@gmail.com>
Co-authored-by: Nicolas <bircni@icloud.com>
Co-committed-by: Nicolas <bircni@icloud.com>
[](https://discord.gg/Gitea)
// Copyright 2026 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT
packagecomments
import(
stdctx"context"
"errors"
"fmt"
"strings"
gitea"gitea.dev/sdk"
"gitea.dev/tea/cmd/flags"
"gitea.dev/tea/modules/config"
"gitea.dev/tea/modules/context"
"gitea.dev/tea/modules/interact"
"gitea.dev/tea/modules/print"
"gitea.dev/tea/modules/theme"
"gitea.dev/tea/modules/utils"
"charm.land/huh/v2"
"github.com/urfave/cli/v3"
)
// CmdCommentsEdit edits an existing comment.
varCmdCommentsEdit=cli.Command{
Name:"edit",
Aliases:[]string{"e"},
Usage:"Edit the body of an existing comment",
Description:`Edit the body of an existing comment by its comment ID. Use 'tea comments list <issue>' to find IDs.
The new body can be supplied as a positional argument, via -d/--description, piped on stdin, or (if none is given and stdin is a terminal) entered in your $EDITOR.`,
ArgsUsage:"<comment id> [<new body>]",
Action:RunCommentsEdit,
Flags:append([]cli.Flag{
&cli.StringFlag{
Name:"description",
Aliases:[]string{"d"},
Usage:"new comment body (alternative to the positional argument)",
},
},flags.AllDefaultFlags...),
}
// RunCommentsEdit updates the body of an existing comment.
// Copyright 2026 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT
packagecomments
import(
stdctx"context"
"fmt"
gitea"gitea.dev/sdk"
"gitea.dev/tea/cmd/flags"
"gitea.dev/tea/modules/context"
"gitea.dev/tea/modules/print"
"gitea.dev/tea/modules/utils"
"github.com/urfave/cli/v3"
)
// CmdCommentsList lists comments on an issue or pull request.
varCmdCommentsList=cli.Command{
Name:"list",
Aliases:[]string{"ls"},
Usage:"List comments on an issue or pull request",
Description:"List comments on an issue or pull request. Comment IDs returned here are the IDs accepted by 'tea comments edit' and 'tea comments delete'.",
ArgsUsage:"<issue / pr index>",
Action:RunCommentsList,
Flags:append([]cli.Flag{
&flags.PaginationPageFlag,
&flags.PaginationLimitFlag,
},flags.AllDefaultFlags...),
}
// RunCommentsList lists comments on the given issue/PR.
ArgsUsage:" ",// command does not accept arguments
Flags:[]cli.Flag{
&cli.StringFlag{
Name:"name",
@@ -89,9 +94,9 @@ var CmdLoginAdd = cli.Command{
Usage:"Use SSH public key or SSH fingerprint to login (needs a running ssh-agent with ssh key loaded)",
},
&cli.BoolFlag{
Name:"helper",
Aliases:[]string{"j"},
Usage:"Add helper",
Name:"git-credentials",
Aliases:[]string{"helper","j"},
Usage:"Register tea as a git credential helper for this login's URL, so 'git push' and 'git clone' over HTTPS authenticate silently using the stored token",
},
&cli.BoolFlag{
Name:"oauth",
@@ -110,10 +115,10 @@ var CmdLoginAdd = cli.Command{
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Renovate Bot
