Git Sync and Populating Scripts.ps1

Product: PowerShell Universal
Version: 3.6.3

Should files synced via Git appear in the Automation > Scripts Admin UI?

I am looking to migrate from an older 2.x install to a current 3.x release. As part of that I setup Git Two-Way Sync on the 3.6.3 host and my idea was to move scripts/schedules from the 2.x to a new dedicated Git repo for the 3.x system to allow for a staged migration over the span of a couple weeks. However, when I create/add a script to the Git repo from my local PC, it gets synced and is created in the Repository folder on the 3.6.3 host but it does not appear in the Admin UI which means it cannot be edited or scheduled from the Admin UI. Is this expected?

Are you also adding the script to the .universal/scripts.ps1 file?

I am not. Because creating a script via the UI adds it to scripts.ps1, I was trying to just confirm this is the expected workflow (e.g. managed scripts.ps1 “manually”, or “as code” [for lack of a better phrase]) with Git integration.

Ah, yes. You need to both add the ps1 to the repository and then add it to scripts.ps1 for it to show up in the admin UI.

Okay, got it. Our current 2.x instance we don’t have Git integration and I always ended up using the UI to generate the empty PS1 (so PSU was aware of it and it was visible), then used VSCode extension to actually interact with it. Thanks!

1 Like

@adam Is there a plan to have git sync automatically add the scripts to the root Repository folder? To me it seems like this would be the expected default behavior.

You mean like if there is a script in the root of the repository folder have it show up in the admin UI?

I mean when, for example, one-way git sync is enabled to have any .ps1 coming in from that sync be created/overwritten in the Repository folder and show up in the admin UI

In full transparency, I did semi-expect a new script brought in via Git sync to add itself to the scripts.ps1 file. I sort of assumed it would create the barebones to get it to appear in the UI (e.g. name = name of script file, no description, environment = default, no credential defined, etc.).

That said, I acknowledge the UI basically assists us in generating the entry, which doing “manually” is a pretty negligible overhead, so it’s really not a big deal to do as part of our workflows.

Agree with @OtherPeoplesCode. I’m just getting my PSU instance spun up for the first time but for me, I’m looking at taking an existing git repository that I have ~150 scripts in and pointing it at PSU. To have to manually create each file, then add a line for each one in the .ps1 seems a bit tedious. As they mentioned, not the end of the world but definitely feels like something you’d expect the system to handle on its own (not knowing how the underlying code is structured and whether this would be a giant pain in the butt or not!).

I am sorry for necroing this thread, but I just ran into this exact same issue. I thought I was doing something wrong with my Git Sync. Have there been any more thoughts about how to handle this more gracefully?

I don’t think it would be possible without a major re-write of the product. Everything in the .universal folder is essentially your app config. PSU generates it when you create scripts, dashboards, etc. in the UI. If you’re doing it in code, PSU has no way to guess which .ps1 files in the repository are meant to be scripts or dashboards or pages and the relevant context (environment, runas accounts, etc.).

1 Like

Thanks for your response. That makes sense to me!

@robderickson Unless I’m misreading or forgetting something, this would be fairly easily doable with a combination of recursing the folders (or a folder) within the repository for any .ps1 files, and using a foreach command to append their names and a generic description to the scripts.ps1 file, triggered on a Git sync happening (which is already a built-in PSU trigger). Adding in some logic to the process, for things like checking if a line already contains the filename to be added, etc. and it should work fairly flawlessly. The scripts that a user generates are not stored in the .universal folder, so ignoring those wouldn’t be an issue.

That could work if you want to implement it yourself, but there are a couple of issues with the product taking that approach:

  1. Not every .ps1 file in your repository is meant to be run as a PSU script. Your apps (dashboards) are .ps1 files as are your app pages and API endpoints.
  2. If your Git sync is one-way and PSU makes changes to its local repository, you’ll have merge conflicts the next time the remote branch is updated and PSU tries to sync it.

If you’re doing a two-way sync, you may as well create the scripts initially in the admin console and let it do the heavy lifting.

  1. This is mostly avoidable by not including the folder(s) those specific scripts are stored in, in the recursive search.

  2. Possibly. Though, this could also be avoided by running the script to add the .ps1 files on the remote side or from a local workstation, push that to the repo that PSU syncs with, and never need worry about such merge conflicts. As for two-way syncs and creating the scripts within PSU initially, you could do that, or you could just use the PSU extension for VSCode, etc.

In any case, this is not an impossible solution and could be accomplished in a matter of minutes. I don’t imagine this being a frequently-needed solution, either, since users wouldn’t be likely to add hundreds or thousands of scripts every day - this would probably be a one-and-done thing, with more scripts being added individually as time goes, rather than in bulk.