create input_set: missing Git flags makes input sets impossible for REMOTE pipelines

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.

Start in pkg/spec/pipeline.spec.yaml at the create input_set definition, then compare its flags and query_params with create pipeline around lines 483–511. Verify the generated help exposes connector, repo, branch, and file-path, and reproduce creation against a REMOTE pipeline; done means those values are forwarded and the input set is accepted by the repository-backed pipeline.