fix(cd): send correct DTO envelope for service/environment/infrastructure -f uploads/create#58
Merged
Merged
Conversation
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
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.
Problem
harness create/update service|environment|infrastructure -f <file>.yamlfailed with:API error 400: identifier: cannot be empty
The Harness
servicesV2,environmentsV2, andinfrastructuresAPIs don't acceptthe plain resource YAML you'd export from Harness Studio (e.g. a bare
service:block). They require a DTO envelope instead: identity fields
(
identifier,name,orgIdentifier,projectIdentifier, ...) at the top level,plus the full resource YAML embedded as a string under a
yamlkey. The CLI's-ffile-body path was JSON-encoding the raw YAML and sending it as-is, so the APIsaw no top-level
identifierand rejected it.Separately,
create/update connector(and other nouns usingcreate_body_wrap/update_body_wrap, e.g. organization/project/secret) had alatent double-wrap bug: if
-fwas given a file already wrapped in its top-levelkey (e.g. a Studio export shaped as
{"connector": {...}}), the CLI would wrap itagain into
{"connector": {"connector": {...}}}.Fix
file_body_yaml_envelope: <key>, and abuildYamlEnvelopehelper in
pkg/registry/endpoint.gothat builds the API's required envelope fromthe
-ffile, handling all three shapes seen in real sample files: already anenvelope (has
yaml:), wrapped (e.g.service:block), or flat (no wrapper).file_body_yaml_envelopeonto the sixcreate/updateendpoints forservice,environment, andinfrastructureinpkg/spec/cd.spec.yaml.unwrapIfAlreadyWrappedguard to the genericcreate_body_wrap/update_body_wrapfile-body path so it detects an already-wrapped-ffile andavoids double-wrapping (fixes the connector edge case and any other noun sharing
this code path).
Testing
Verified live against a real Harness account:
harness update service <id> -f service.yml— previously400, now succeeds.harness update environment <id> -f environment.yml(flat shape) — succeeds.harness update infrastructure <id> -f infrastructure-definition.yml(alreadyenvelope shape) — succeeds.
harness update connector <id> --set description=...— sanity-checked unaffected.