Skip to content

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

Description

@3choBoomer

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions