feat(distribution): publish AUR packages (clickupcli, clickupcli-bin, clickupcli-git)

[ulises-jeremias]

Motivation

Right now clickup (the CLI binary) is installable via Homebrew, go install, or direct binary download from the GitHub release. Arch Linux and its derivatives (Manjaro, Endeavour, Garuda, CachyOS, etc.) — a non-trivial share of the CLI-power-user audience — have no first-class install path. Adding official AUR packages fills that gap, mirrors the distribution story we already have for Homebrew/Linux + macOS, and makes adoption a one-liner (yay -S clickupcli-bin).

I'd like to offer to do the implementation, and I'm also happy to remain the long-term AUR maintainer since Arch + ClickUp are tools I use daily.

Existing AUR landscape (FYI)

A quick search turned up these existing entries:

Package	Maintainer	Version	Notes
clickup	alhirzel	3.5.230-2	The ClickUp desktop AppImage — well-maintained, 16 votes, untouchable. Same name conflict Homebrew has with the clickup cask.
clickup-cli-bin	nicholaswbester	0.14.0-1	0 votes, last updated 2026-06-24, points at a personal fork (nicholasbester/clickup-cli), 21 releases behind upstream. Effectively abandoned.

I'm intentionally not proposing a takeover of clickup-cli-bin to keep the contribution small and avoid coordination overhead with a third party. The clickupcli* family (no hyphen) is free in AUR, doesn't conflict with the desktop package, and is easy to disambiguate from the existing stale entry. If the maintainer prefers the hyphenated clickup-cli* family and wants to negotiate the takeover, I'm open to that too — just say the word.

Proposed AUR packages

Package	Source	Tracks	Recommended for
clickupcli	Build from source (go build)	Stable tags (vX.Y.Z)	Purists / reproducible builds
clickupcli-bin	Prebuilt tarball from GitHub release	Stable tags (vX.Y.Z)	Default — fast, no go toolchain needed (mirrors Homebrew's bin.install)
clickupcli-git	Build from source, VCS	main branch	Early adopters
clickupcli-bin-git	(out of scope for this PR — add later if requested)	—	—

The binary in all packages installs as /usr/bin/clickup (matching the official binary name and what Homebrew/macOS/Windows users get) with conflicts=('clickup') and provides=('clickup') to handle the desktop coexistence cleanly — same trick .goreleaser.yml:43 already uses for the Homebrew formula.

Implementation outline

• New directory contrib/aur/clickupcli{,-bin,-git}/ each containing a PKGBUILD and a generated .SRCINFO.
• New workflow .github/workflows/aur-publish.yml triggered on:
  • push of tags matching v* (reuses the existing GoReleaser release)
  • workflow_dispatch (manual bump if needed)
    The workflow generates updated PKGBUILD / .SRCINFO for the matching package and calls ulises-jeremias/github-actions-aur-publish (an MIT-licensed action I maintain and use on other AUR-published projects) once per package in parallel.
• README + docs/src/content/docs/installation.mdx gain a new "Arch Linux (AUR)" section under the existing install methods.
• No changes to the binary itself, no impact on Homebrew/Linux/macOS users.

Secrets (provided later, after maintainer approval)

The new workflow needs three repository secrets — I'll provide them via a one-time secret share once you're happy with the plan:

• AUR_SSH_PRIVATE_KEY — SSH key with push access to aur.archlinux.org
• AUR_USERNAME — AUR account to commit as
• AUR_EMAIL — AUR git committer email

AUR account ownership stays with whoever you (the maintainer) want; I'm happy to be the long-term committer, co-maintainer, or just hand it off entirely.

Future expansion (out of scope here, but worth noting)

If this lands cleanly, a follow-up PR could add:

• Scoop (Windows) — a manifest in a triptechtravel/scoop-bucket repo, fed by the same GoReleaser artifacts
• winget (Windows) — open a PR against microsoft/winget-pkgs
• Nix / nixpkgs — a derivation
• Snap — snapcraft.yaml
• Single-line curl | sh installer — scripts/install.sh that auto-detects OS/arch and drops the binary in /usr/local/bin (useful for barebones containers / WSL / anything without a package manager)

Each is a small, isolated PR once the AUR pipeline is battle-tested.

Offer

Happy to open the PR as soon as you give the green light. I already have:

• An AUR-maintainer track record on a few other projects
• Previous PRs in this repo (feat: add clickup doc command group with Docs and Pages support #11) so I'm familiar with the codebase and review style
• The CI/CD action (ulises-jeremias/github-actions-aur-publish) and patterns ready to wire up

Let me know if you'd prefer:

1. The clickupcli* family as proposed, or
2. Coordinate a takeover of the existing stale clickup-cli-bin and use the hyphenated family, or
3. Defer until after the next release to keep this PR small.

[isaacrowntree]

Thanks for the thorough writeup — the naming analysis and the conflicts/provides=('clickup') mirroring of our Homebrew trick are exactly right, and the offer to maintain it long-term is appreciated.

I want to greenlight this, but scoped down. One thing the outline doesn't account for: this repo doesn't commit its generated API code. api/*/client.gen.go and internal/apiv{2,3}/operations.gen.go are all gitignored and produced by make api-gen at build time, which:

• curls two OpenAPI specs from developer.clickup.com (unversioned, living URLs)
• go installs oapi-codegen@latest
• runs jq / perl / go run ./cmd/gen-api

GoReleaser gets away with this because it runs on a networked CI runner. A from-source makepkg build can't — build() is expected to run offline, and pinning the specs as source=() with sha256sums means the checksums rot whenever ClickUp edits the spec, which is on their schedule, not ours.

So I'd like to land clickupcli-bin first and defer clickupcli / clickupcli-git. The -bin package repackages the existing GoReleaser clickup_linux_{amd64,arm64}.tar.gz artifacts + checksums.txt, needs zero changes to the release pipeline, and is the default you're recommending anyway. That gets Arch users the one-liner with none of the codegen fragility and a much smaller review/secrets surface.

A few asks if you're up for it:

1. Scope the PR to clickupcli-bin only. If you've got a clean answer for the uncommitted-codegen problem on the source builds (a --nocheck-friendly PKGBUILD vendoring a pinned spec snapshot?), I'm happy to look at it as a follow-up — but let's not block the -bin package on it.
2. Docs note: the install page is docs/src/content/docs/installation.md (not .mdx), and its intro hard-codes "three ways to install" — that'll need bumping.
3. On the third-party ulises-jeremias/github-actions-aur-publish action and the AUR_SSH_PRIVATE_KEY secret landing in our release path — I'd want to pin it to a full commit SHA rather than a tag. No objection in principle.

Separately, your "future" curl | sh installer is arguably higher-leverage than the source AUR packages and needs no per-distro maintainer — worth a small standalone PR whenever you feel like it.

If scoped to -bin as above, consider this a green light — open the PR whenever you're ready.

[isaacrowntree]

Following up on the above — no rush, just flagging a change on our side.

I went ahead and did the curl | sh installer from your "future expansion" list: #22. It seemed like the piece with the least coordination cost, so it made sense to knock out while the AUR question was open. It consumes the existing GoReleaser artifacts and changes nothing about the release pipeline, so it shouldn't collide with anything you'd be doing for AUR.

Two things in there that are probably relevant to the -bin PKGBUILD, since they're the same artifacts:

• https://github.com/triptechtravel/clickup-cli/releases/latest/download/<asset> resolves server-side, so you can avoid the GitHub API (and its rate limit) entirely for latest-version resolution.
• The release ships checksums.txt in the <sha256> <filename> format, so sha256sums in the PKGBUILD can be generated straight from it rather than recomputed.

The offer from my earlier comment stands unchanged: green light for clickupcli-bin, with clickupcli / clickupcli-git deferred until there's a good answer for the uncommitted-codegen problem. If you'd still like to take that on, it's yours — just say so and I'll leave it alone.

If you'd rather not, or your plans have changed, no hard feelings at all and thanks for the thorough writeup either way — the naming research in particular saved me a lot of time. I'd just want to know so I can decide whether to pick up the -bin package myself or close this out.