Support updating pipeline metadata tags from YAML during bi-directional sync
long-term
R
Regular Dinosaur
Currently, when YAML is stored in GIT, and tags are added or updated directly in the YAML file within GIT, those changes do not update the pipeline metadata. As a result, the pipeline metadata does not reflect the new or modified tags.
During execution, tags are read from the pipeline metadata — not from the YAML file — so executions do not display the updated tags.
This is the expected behavior with the current bi-directional sync mechanism. However, this creates a gap between the tags defined in YAML and the metadata used during execution.
Enable the pipeline metadata to be automatically updated when tags are modified in the GIT-stored YAML file, ensuring metadata and YAML remain synchronized for tags as part of bi-directional sync.
Log In
F
Flame Raven
+1. We are actively receiving negative feedback from our developers regarding this matter.
F
Fawn Rabbit
We are experiencing the same limitation with Git-stored pipelines. After tags are changed in the canonical Git branch and the pipeline is reconciled, the new tags appear in Pipeline Studio but are not propagated to the entity metadata used by the Pipeline List, filtering, and tag-based RBAC. The metadata remains stale until someone performs an otherwise unnecessary save through the UI or API.
We understand that automatically synchronizing tags from arbitrary branches would be ambiguous. We therefore suggest a deterministic, branch-aware synchronization mechanism:
• Allow a default or explicitly configured branch to be designated as the authoritative source for pipeline metadata.
• When that branch is successfully reconciled, synchronize tag additions, changes, and removals with the entity metadata.
• Changes from non-authoritative branches should not modify the global metadata.
• Do not require an additional UI or no-op API save.
This would address the multi-branch ambiguity while preserving Git as the source of truth and preventing silent discrepancies between Pipeline Studio, the Pipeline List, filtering, and RBAC behavior.
F
Flamingo pink Salamander
temporary workaround - we have solved this (for now) by calling a no-op UPDATE request in our CI systems on merge to main. Basically reading the current pipeline config on default branch and using this api endpoint: https://apidocs.harness.io/pipelines/update-pipeline
we've noticed that if your update config matches the live config, it won't attempt to do an SCM commit, but will still update the tags in the API/ListPipeline endpoints.
Confirmed that this approach works at least for Service entities and Pipeline entities.
Sudarshan Purohit
updated the status to
long-term
Sudarshan Purohit
Thank you for your request. With the current design, this is difficult to solve, since we can only update the Pipeline Metadata tags when the Pipeline is saved in the UI (because different versions of the Pipeline in different branches may have different tags).
I would like to point out, though, that the Pipeline Execution instance does read the tags from the executing Pipeline YAML to maintain consistency there.
We are internally evaluating ways to resolve this problem and may have a redesign of the Tags system to solve it in the coming year. We will keep this ticket updated as we have a solution.
a
abhijit.pujare
updated the status to
under review
Y
Yellowwood Bear
+1. For my team, managing pipelines through GIT is very important, as it saves us significant time. I also believe that if pipelines are supported in the GIT Experience, all their elements should be updated properly using IaC.
F
Functional Dolphin
+1 on this
F
Flamingo pink Salamander
+1 on this - we depend on tags for a few things, including deployment ordering and entity retrieval in more complex pipelines. We very badly need a reliable way to propagate tags from remote entity YAML into the API fields.