HarperFast / HarperFast/harper

CLI: `harper deploy by_ref=true` — deploy by git reference

Open
#1,777 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.