test: cover remote input set git context edge cases (PR #579)#580
Draft
cursor[bot] wants to merge 2 commits into
Draft
test: cover remote input set git context edge cases (PR #579)#580cursor[bot] wants to merge 2 commits into
cursor[bot] wants to merge 2 commits into
Conversation
Running a v0 pipeline via harness_execute with input_set_ids for a
remote / Git-stored input set silently applied the wrong values (or none):
the input-set GET forwarded only org/project/pipeline identifiers and no
git context, so the Harness API resolved the set from the repo's DEFAULT
branch. When the input set lived on another branch, the run proceeded with
default-branch content and no error — matching the reported "pipeline runs
but the input set isn't applied."
Verified against the live Harness API: GET /pipeline/api/inputSets/{id}
honors branch/repoName/connectorRef/storeType query params, and omitting
branch silently falls back to the default branch (returns SUCCESS with the
wrong YAML). The response field names (inputSetYaml, inputSet.pipeline)
were already correct.
Changes:
- materializeInputSetsToRuntimeYaml accepts an optional gitContext and
forwards branch/repoName/connectorRef/storeType on each input-set GET.
- harness_execute builds gitContext from the run's already-normalized
remote params (pipeline_branch/branch, repo_name, connector_ref,
store_type) and passes it through. Inline sets are unaffected — empty
values are dropped by the client's query serializer.
- The standalone input_set get action gains the same git query params,
fixing the parallel silent-default on harness_get(resource_type=input_set).
Adds tests: git-context forwarding in materialize, and end-to-end
forwarding from a remote pipeline run into the input-set GET.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
AI-Session-Id: b8e26a07-057c-406c-bfde-245eb0c917ae
AI-Tool: claude-code
AI-Model: unknown
Add regression tests for PR #579 gaps: - Registry input_set GET maps branch/repo/connector/store_type query params - pipeline_branch takes precedence over branch for input set materialization - Git context forwarded when merging input_set_ids with full pipeline YAML - Git context applied on every GET when multiple input sets are materialized Co-authored-by: Rohan Gupta <thisrohangupta@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds regression tests for the git-context forwarding fix in #579 (
fix/execute-input-set-remote-git-context). The original PR covered the happy path; this PR closes gaps where silent wrong-branch resolution could still regress.Risky behavior now covered
input_setGET —branch,repo_name,connector_ref, andstore_typequery params reach the Harness API (previously omitted frompipelines.tsget spec)pipeline_branchprecedence — when bothpipeline_branchandbranchare set on a remote run, input set materialization usespipeline_branch(the git branch the set YAML lives on), not the CI codebase checkout branchinput_set_idsare merged alongside a full pipeline document ininputsTest files added/updated
tests/registry/input-set-git-context.test.tsinput_setget with/without git paramstests/tools/tool-handlers.test.tspipeline_branchprecedence + git context on merge-with-full-YAML pathtests/utils/materialize-input-sets.test.tsinputSetIdsWhy these tests materially reduce regression risk
Remote/git-backed input sets fail silently — Harness resolves from the repo default branch with no error when branch params are missing. These tests pin the three integration surfaces (
harness_getregistry dispatch,harness_executematerialization, and thematerialize-input-setsutility) so a dropped query param or wrong branch field cannot re-ship unnoticed.Type of Change
Checklist
pnpm testpasses (targeted: 158 tests in 3 files)pnpm typecheckpassespnpm buildpassespnpm standards:checkpassespnpm docs:checkpasses (N/A — no registry/tool count changes)