Can you export a qvf to a folder in a GitHub repo? And better way than nested if conditions?

[OdieW]

I am using the automation template for exporting an app to github. It works great as is, but I am trying to decide on the best organization strategy for GitHub. Since the automation works off managed space I made a repo for each managed space, but I am thinking things will get a bit chaotic because we have multiple apps per managed space. So I was thinking about adding folders to the repos for each app. I added the folder and tried using just the folder name as well as repo/folder name for the repo field in the automation but neither works. I am wondering if I have the formatting wrong or if its just not possible.

If that is not possible I may create repo's for each app regardless of shared space, but then I would need to edit the automation to look at what the app name is and based on that send it to the correct repo for that app. I think I can do this with nested if conditions but thinking that will be very clunky. I am wondering if I am missing an easier option. Maybe something that compares the app name against a list of key/pair values and based on a match it uses that key/pairs repo, but I'm not sure if that will work or exactly how to implement it yet. My concern with this approach is that it relies on us remembering to add new apps to each automation. Whereas the current one does not care if the app is new or not, it will export it when its published.

Alternatively since I already have an automation for each manages space. I could edit each one of them to check for the 3ish apps that are in each managed space and assign a repo to it. That would definitely make for less condition blocks if I can't figure out how to make the key/value pairs check work.

Thanks!

[DaveChannon · Accepted solution]

In git, there isn't really a true concept of folders, but if you put folder/file.qvf it's going to appear nicely in the UI and on disk in the folder/ directory. So just put the folder into the filename in automations and it'll work fine.

I suggest an automation per space and a repo per space is the lowest you want to go. If you're doing this for tenant wide backup (i.e. it's managed by one team) then I'd even suggest you just put it all into one repo, and use a single automation to handle the whole thing - it'll make it much easier to track and manage.

Other things to think about:

1. How do you handle name changes for spaces - consider using the space ID in the path rather than name
2. How do you handle name changes for apps - consider using the app ID
3. How do you handle moves of apps between spaces - you will want to track this or at least true it up so if someone moves an app to another space and doesn't republish it, then you'll be able to track it down if someone needs a copy of it (unless you use app ID for the file name, in which case it'll be easier)

[OdieW]

Thanks for the great info Dave. If we go with one repo for everything how is that managed/kept organized? I would personally want to do the folders especially in a monorepo, but also want to make sure I'm not straying from a best practice I may not be familiar with.

The automation already uses App Id and Space Id so I think we are good there, but I had not considered apps moving to another space. Something I will have to consider.