provide an option to delete the pipeline,inputset etc yaml file from git when corresponding object is deleted
long-term
N
Novel Cod
Currently without bidirectional git enabled, if an object backed by remote git (pipeline, input set, template) etc is deleted from Harness UI, the yaml is left behind on git. It may be for safety reason. But it causes deleted object yamls to accumulate in git . Plus there is no need to keep it in git for safety reason because if a user wants to retrieve the yaml they can always get it from a previous commit. A radio button option to let user decide if it should be deleted from git would be great
Log In
Rohan Gupta
open
A
Aegean blue Quail
I strongly agree. Git Experience should mean that the Git repo is an accurate, current mirror of what's in Harness, not a half-baked backup drive.
Not deleting files in Git leads to many different problem scenarios:
1) "Work in progress" lives forever.
I need to make some changes in Harness for a new feature.
I change some templates and save them to a new feature branch in Github.
After working on the changes for a while, I no longer need several of the templates that I made, and I delete them in Harness.
However, they will still remain in Git, and when I create a Pull Request for the team to review, they see these "draft" templates which are still in Git but no longer exist in Harness. The purpose of a pull request is to review the exact changes that are going live. The PR does not reflect that.
The only fix is to manually delete the files from git to achieve an accurate PR state.
2) Name Collisions.
Create a template. Save it to Git. Delete the template in Harness. It continues to live in Git.
If at some later point I create a template with that same name and version, I get an error, because a file of that name already exists.
3) Accurate mirror of Harness.
We have several thousand templates/versions. One of the big appeals of moving to Git Experience is that we can check out all our Harness configurations to disk, so that we can see/search/analyze it more effectively.
For example, search through all templates to find all occurrences of a particular API key / URL / script / etc.
However, by not deleting flies in git when we delete a file in Harness, the git repo is no longer an accurate mirror of the current state. Instead, it's a crufty bucket of every version of every file that we've ever touched. If I search for something and find 200 files that have that string, I now have to determine if each of those 200 hits are files that still exist in Harness, or if they are old versions of templates that have long been deleted.
4) All of these problems get worse over time, because the git directories will just continually grow.
Git is a tool that is explicitly made to store all changes for all time. Don't treat it like a network drive.
From my perspective, there shouldn't even be a user-facing option to delete or not. Harness should always keep an accurate representation in Git. Allowing individual users to toggle a "delete in git" button means that some users will choose to not delete in Git, and then Git won't be an accurate mirror of Harness.
Prasad Satam
long-term
Thanks for the feedback! This enhancement request has been given top priority and is now officially in our development pipeline!
We will keep you updated on the progress and let you know as soon as it is available.
Should you have any questions, suggestions, or thoughts you'd like to share, please feel free to add more to this feature request.
Rohan Gupta
open
Rohan Gupta
Merged in a post:
When deleting a pipeline with Harness Git Experience enabled, the delete does not occur in git
C
Colourful Dormouse
enhancement request to update the documentation? It shows that I can pass a commit message and git branch and such on the delete call. To me this indicates that what I am experiencing is not intended and is instead a bug.
There should also be a note about this on the git experience page. This is not how a reasonable person would expect this experience to work. If you create the file on create, I would expect you to delete the file on delete. Re-using the yaml is an advanced feature we have no plans to leverage.