Lunny Xiao
61b8536e4a
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>
T E A
The official CLI for Gitea
NAME:
tea - command line tool to interact with Gitea
USAGE:
tea [global options] [command [command options]]
VERSION:
Version: 0.10.1+15-g8876fe3 golang: 1.25.0 go-sdk: v0.21.0
DESCRIPTION:
tea is a productivity helper for Gitea. It can be used to manage most entities on
one or multiple Gitea instances & provides local helpers like 'tea pr checkout'.
tea tries to make use of context provided by the repository in $PWD if available.
tea works best in a upstream/fork workflow, when the local main branch tracks the
upstream repo. tea assumes that local git state is published on the remote before
doing operations with tea. Configuration is persisted in $XDG_CONFIG_HOME/tea.
COMMANDS:
help, h Shows a list of commands or help for one command
ENTITIES:
issues, issue, i List, create and update issues
pulls, pull, pr Manage and checkout pull requests
labels, label Manage issue labels
milestones, milestone, ms List and create milestones
releases, release, r Manage releases
times, time, t Operate on tracked times of a repository's issues & pulls
organizations, organization, org List, create, delete organizations
repos, repo Show repository details
branches, branch, b Consult branches
actions Manage repository actions (secrets, variables)
comment, c Add a comment to an issue / pr
webhooks, webhook Manage repository webhooks
HELPERS:
open, o Open something of the repository in web browser
notifications, notification, n Show notifications
clone, C Clone a repository locally
MISCELLANEOUS:
whoami Show current logged in user
admin, a Operations requiring admin access on the Gitea instance
SETUP:
logins, login Log in to a Gitea server
logout Log out from a Gitea server
GLOBAL OPTIONS:
--debug, --vvv Enable debug mode (default: false)
--help, -h show help
--version, -v print the version
EXAMPLES
tea login add # add a login once to get started
tea pulls # list open pulls for the repo in $PWD
tea pulls --repo $HOME/foo # list open pulls for the repo in $HOME/foo
tea pulls --remote upstream # list open pulls for the repo pointed at by
# your local "upstream" git remote
# list open pulls for any gitea repo at the given login instance
tea pulls --repo gitea/tea --login gitea.com
tea milestone issues 0.7.0 # view open issues for milestone '0.7.0'
tea issue 189 # view contents of issue 189
tea open 189 # open web ui for issue 189
tea open milestones # open web ui for milestones
tea actions secrets list # list all repository action secrets
tea actions secrets create API_KEY # create a new secret (will prompt for value)
tea actions variables list # list all repository action variables
tea actions variables set API_URL https://api.example.com
tea webhooks list # list repository webhooks
tea webhooks list --org myorg # list organization webhooks
tea webhooks create https://example.com/hook --events push,pull_request
# send gitea desktop notifications every 5 minutes (bash + libnotify)
while :; do tea notifications --mine -o simple | xargs -i notify-send {}; sleep 300; done
ABOUT
Written & maintained by The Gitea Authors.
If you find a bug or want to contribute, we'll welcome you at https://gitea.com/gitea/tea.
More info about Gitea itself on https://about.gitea.com.
- tea uses gitea.dev/sdk and interacts with the Gitea API.
Installation
There are different ways to get tea:
-
Install via your system package manager:
-
Use the prebuilt binaries from dl.gitea.com
-
Install from source: see Compilation
-
Docker: Tea at docker hub
Log in to Gitea from tea
Gitea can use many different authentication schemes, and not every authentication method will work with every Gitea deployment. When you are a Gitea instance administrator you can tweak your settings to fit your use case. For the method that is most likely to work with any Gitea deployment use the following steps:
-
Open your Gitea instance in a web browser
-
Log in to Gitea in your web browser. Any MFA, IDP, or whatever else should be available this way.
-
In your "user settings", generate an application token with at least user read permissions. If you want to do anything useful with the token add additional permissions/scopes.
-
Run
tea login add, select application token authentication when asked for authentication type, and answer yes to the question if you have a token. Paste the generated token when asked for one.
You should now be logged in to your gitea instance from tea.
Since 0.10 Gitea supports the much simpler oauth workflow but oauth may not be available on all Gitea deployments, and gets much more complex when running tea on a remote system.
Shell completion
If you installed from source or the package does not provide the completions with it you can add them yourself with tea completion <shell> command which is not visible in help. To generate the completions run one of the following commands depending on your shell.
# .bashrc
source <(tea completion bash)
# .zshrc
source <(tea completion zsh)
# fish
tea completion fish > ~/.config/fish/completions/tea.fish
# Powershell
Output the script to path/to/autocomplete/tea.ps1 an run it.
Man Page
The hidden command tea man can be used to generate the tea man page.
# for bash or zsh
man <(tea man)
# for fish
man (tea man | psub)
# write man page to a file
tea man --out ./tea.man
Compilation
Make sure you have a current Go version installed (1.26 or newer).
-
To compile the source yourself with the recommended flags & tags:
git clone https://gitea.com/gitea/tea.git # or: tea clone gitea.com/gitea/tea ;) cd tea makeNote that GNU Make (gmake on OpenBSD) is required. If you want to install the compiled program you have to execute the following command:
make installThis installs the binary into the "bin" folder inside of your GOPATH folder (
go env GOPATH). It is possible that this folder isn't in your PATH Environment Variable. -
For a quick installation without
git&make, set $version and exec:go install gitea.dev/tea@${version}
Contributing
Fork -> Patch -> Push -> Pull Request
make testrun testsuitemake vetrun checks (check the order of imports; preventing failure on CI pipeline beforehand)- ... (for other development tasks, check the
Makefile)
Please read the CONTRIBUTING documentation, it will tell you about internal structures and concepts.
License
This project is under the MIT License. See the LICENSE file for the full license text.