HarperFast / HarperFast/harper
CLI: `harper deploy by_ref=true` — deploy by git reference
- Dominant language
- JavaScript
- Stars
- 89
- Forks
- 10
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 200
Description
## Problem
`create-harper` scaffolds a per-project `scripts/deploy.mjs` to deploy by git reference; that logic is client-side (it reads the local git repo), so it belongs in the `harper` CLI — then no scaffolded project needs to carry a script.
## Proposal
Opt-in flag on `harper deploy` / `deploy_component`. When `package=` is absent **and** `by_ref=true` (or `ref=`) is passed, the CLI:
- resolves `owner/repo` from `GITHUB_REPOSITORY` or the `origin` remote,
- resolves the committish from `ref=`, else `GITHUB_SHA`, else `git rev-parse HEAD`,
- warns if the working tree is dirty,
- defaults `project` from `package.json`,
- sets `package=git+https://github.com//.git#`.
Pinning by **SHA** (not tag) avoids cluster peers diverging on a moved tag. **git+https, not ssh** — a private clone is authenticated by a git-host token credential (#1799), which rides over HTTPS.
For a private repo, **`credential=github.com`** (or `credential=true`) attaches a `credentials` reference `[{ host, secret: "deploy.." }]` — the durable token sealed once by `harper deploy setup=true` (#1778) — which the cluster resolves **in-memory** to authenticate the clone. A public repo needs no credential.
The **no-flag default stays the payload deploy** (backward-compatible). `by_ref`/`ref`/`credential` are transport-only (consumed client-side); `credentials` is a real operation field and is sent.
## Prototype
Branch [`claude/deploy-by-ref-flag`](https://github.com/HarperFast/harper/tree/claude/deploy-by-ref-flag) — `bin/cliOperations.ts`, in `PREPARE_OPERATION.deploy_component`. Parse + oxlint + prettier clean.
## Related — deploy-by-reference effort
- `HarperFast/harper#1849` — two-phase stage/activate + `revert_component`
- `HarperFast/harper#1850` — `harper deploy by_ref=true` (deploy by git reference)
- `HarperFast/harper#1851` — `harper deploy setup=true` (client-side sealed deploy credential)
- `HarperFast/harper#1876` — CI token auth + `harper login --for-ci`
- `HarperFast/harper-pro#594` — `add_ssh_key generate=true` (cluster-side keygen)
- `HarperFast/create-harper#118` — scaffolds this flow
- `HarperFast/documentation#599` — two-phase deploy docs
- `HarperFast/documentation#616` — by-reference / sealed-credential / CI-auth docs
Contributor guide
Research direction
Start in bin/cliOperations.ts at PREPARE_OPERATION.deploy_component, then inspect the existing create-harper scripts/deploy.mjs behavior and the claude/deploy-by-ref-flag prototype. Verify parsing, repository and commit resolution, dirty-tree warnings, project defaults, package construction, and credential forwarding; done means the opt-in flow works while the payload deploy remains the default.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github, node.js, typescript
- Domain
- cli, developer-experience
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100