Closed brhahlen closed 7 years ago
I had considered doing that, but the "Create CI" Task does not do this either, so I opted against it. In the pipeline that I have, I now use a "Does CI Exist" task in front of the "Create Folder" task (which is now just a script), which then outputs a True/False variable, which is the precondition for this task. I do the same for a "Create Application" task (which is also a "Create CI" task).
Additionally: I specifically chose to do a "PUT" in the HTTP-request, to ensure that if you want to create, for instance, a "folder1/folder2" and a "folder1/folder3" the command will not break on the existence of the "folder1" folder (which is what a POST would do for you).
I'd suggest Create CI Task should be amended to check first then :)
Create CI is doing a POST not a PUT -which as you point out should throw an error. So we should be error handling earlier and not letting the REST API return it's ugly failure.
In this case, if you have Applications/folder1/folder2/folder3/folder4/ - you could end up making multiple calls for something that already exists. An extra does_ci_exist call adds a single call, but could save 5 calls.
Doing the previous task yourself using the Does CI Task Exist is good - but you're forcing other users to think of that optimisation by themselves. Plus, if we have to make 20 folders at once, that's 20 extra Does CI Exist tasks.
If we build it in, we can assure the user that if this task passes, the Folder definitively exists - either because we've checked it or because we made it.
I'm going to start in the middle of your comment, because yes, you could save 5 calls, but you could also add additional calls. Suppose I want to create "Applications/folder1/folder2/folder3/folder4". I do a "Does CI Exist" on the full path first, and find that the full path does not exist. I would then go ahead and do my "Create Folder (Tree)" task. Within this task, I would then have to check for each separate folder whether or not the CI exists. So, that would add, in this example, 3 "Does CI Exist" calls, and then also the additional calls to create the folders. Using the PUT basically an update in this case, which creates it if it doesn't exist, and "updates" it if it already exists.
For the 20 folders at once, those checks would still be there, because of my point above.
Ah, I see what you mean.
I didn't mean to suggest doing a check_ci_exist every time - I just meant a single check. at the start around line 14 of createFolder.py.
If the folder as given by the user exists, just pass. If it doesn't, then roll on through the folder tree as per. That way, no more than 1 extra call when it doesn't exist and only one call when it does.
I discussed with Joris on this, and we decided to go ahead with the combination of check_ci_exists and create_directory methods, so as to make sure there is consistency in the plugin. The amount of calls it makes shouldn't be something bad, as XLD should be able to handle it without problem. So, I've adjusted the plugin to use the check_ci_exists and the create_directory methods. It should be okay now :-)
D'oh! Should have looked at the commits first :) Nice one - I've got a use for this bad boy coming up on my radar.
Created "Create Folder (Tree)" task, that can create a full folder tree in XLD, without having to create multiple tasks for it. It will traverse through the ID provided and create the folder structure in the Type (Applications/Environments/Infrastructure/Configuration) provided