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>
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>
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>
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
This PR adds validation for the `--object-format` flag in the `repo create` command. The flag now accepts only `sha1` or `sha256` as valid values, and returns an error for any other value.
Changes:
- Added validation in `runRepoCreate` to check for valid object format values
- Added unit tests to verify the validation logic
- Fixed the field name from `ObjectFormat` to `ObjectFormatName` to match the SDK
The changes ensure that users get clear error messages when using invalid object format values, improving the user experience.
Fix#727Fix#660Fix#767
Co-authored-by: techknowlogick <techknowlogick@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/tea/pulls/741
Reviewed-by: TheFox0x7 <thefox0x7@noreply.gitea.com>
Lunny Xiao