Summary
create input_set accepts no Git/remote flags, so it always creates an inline input set. Harness requires an input set to live in the same repo as its pipeline, so for any REMOTE (Git-backed) pipeline every CLI-created input set is rejected. There is no -f-plus-git-details path and no import command, leaving no working way to create an input set for a Git-backed pipeline via the CLI.
This is an asymmetry inside a single spec file: create pipeline has the four git flags, create input_set has none.
Related: #210 — together these mean a Git-backed pipeline cannot be set up through the CLI alone.
Version
harness version 3.6.2 (2026-09-01T01:13:47Z)
Also verified against pkg/spec/pipeline.spec.yaml on main (v3.7.1) — unchanged.
Reproduction
Against a pipeline whose store_type is REMOTE:
$ harness create input_set MyPipeline -f .harness/pr_input_set.yaml --project MyProject
API error 400: 1) Please check if account level setting:
[Allow different repo for Pipeline and InputSets] is enabled.
2) Please check if requested input-set is in same repository as the linked pipeline.
There are no flags to satisfy (2):
$ harness create input_set --help | grep -iE "connector|repo|branch|file-path"
(no output)
Expected: an input set created in the same repo/branch as the pipeline, store_type: REMOTE.
Actual: 400; the only creatable form is inline, which a REMOTE pipeline won't accept.
Root cause
pkg/spec/pipeline.spec.yaml:
create pipeline (L483–511) declares the git flags and forwards them as query params:
flags:
- name: connector
- name: repo
- name: branch
- name: file-path
endpoint:
query_params:
storeType: 'flags.repo != "" ? "REMOTE" : ""'
connectorRef: flags.connector
repoName: flags.repo
branch: flags.branch
filePath: flags["file-path"]
create input_set (L1044–1057) declares none:
- command: create input_set
verb: create
noun: input_set
short: Create an input set for a pipeline (-f input-set.yaml)
requires_id: true
handler_type: endpoint
endpoint:
method: POST
path: /pipeline/api/inputSets
file_body: required
content_type: application/yaml
query_params:
pipelineIdentifier: ctx.id
The input_set noun already exposes a store_type field (expr: it.storeType), so the CLI can display REMOTE input sets — it just can't create one.
Suggested fix
Mirror create pipeline: add --connector, --repo, --branch, --file-path to create input_set, forwarding storeType/connectorRef/repoName/branch/filePath. update input_set and delete input_set likely need the same treatment for remote entities.
An input_set:import command (matching the pipeline import request in the related issue) would also help, since input set files are usually committed alongside the pipeline.
Secondary note: confusing error when the id is misread
create input_set takes the pipeline id positionally (requires_id: true + pipelineIdentifier: ctx.id), which is consistent with create trigger, but easy to get wrong because get/update/delete input_set all take <pipeline/id>. Passing the input set id yields a misleading error:
$ harness create input_set pr_input_set -f .harness/pr_input_set.yaml --project MyProject
API error 400: Invalid request: Pipeline identifier in input set does not match
$ harness create input_set MyPipeline/pr_input_set -f ... --project MyProject
create input_set: <id> must not contain '/' (got "MyPipeline/pr_input_set")
Naming the arg <pipeline_id> in usage/help (as create trigger does) would remove the ambiguity.
Workaround
Delete the committed input set files, then let create author them back with the intended content — the create endpoint writes the YAML you pass to file_path. Clumsy, and it puts Harness's own commits on your branch.
Summary
create input_setaccepts no Git/remote flags, so it always creates an inline input set. Harness requires an input set to live in the same repo as its pipeline, so for any REMOTE (Git-backed) pipeline every CLI-created input set is rejected. There is no-f-plus-git-details path and no import command, leaving no working way to create an input set for a Git-backed pipeline via the CLI.This is an asymmetry inside a single spec file:
create pipelinehas the four git flags,create input_sethas none.Related: #210 — together these mean a Git-backed pipeline cannot be set up through the CLI alone.
Version
Also verified against
pkg/spec/pipeline.spec.yamlonmain(v3.7.1) — unchanged.Reproduction
Against a pipeline whose
store_typeisREMOTE:There are no flags to satisfy (2):
Expected: an input set created in the same repo/branch as the pipeline,
store_type: REMOTE.Actual: 400; the only creatable form is inline, which a REMOTE pipeline won't accept.
Root cause
pkg/spec/pipeline.spec.yaml:create pipeline(L483–511) declares the git flags and forwards them as query params:create input_set(L1044–1057) declares none:The
input_setnoun already exposes astore_typefield (expr: it.storeType), so the CLI can displayREMOTEinput sets — it just can't create one.Suggested fix
Mirror
create pipeline: add--connector,--repo,--branch,--file-pathtocreate input_set, forwardingstoreType/connectorRef/repoName/branch/filePath.update input_setanddelete input_setlikely need the same treatment for remote entities.An
input_set:importcommand (matching the pipeline import request in the related issue) would also help, since input set files are usually committed alongside the pipeline.Secondary note: confusing error when the id is misread
create input_settakes the pipeline id positionally (requires_id: true+pipelineIdentifier: ctx.id), which is consistent withcreate trigger, but easy to get wrong becauseget/update/delete input_setall take<pipeline/id>. Passing the input set id yields a misleading error:Naming the arg
<pipeline_id>in usage/help (ascreate triggerdoes) would remove the ambiguity.Workaround
Delete the committed input set files, then let
createauthor them back with the intended content — the create endpoint writes the YAML you pass tofile_path. Clumsy, and it puts Harness's own commits on your branch.