Unable to Create Secrets after switching to database persistence

PowerShell Universal
1 
Product: PowerShell Universal
Version: 5.6.12

After some thinking I decided I didn’t want to store variables in my variables.ps1 file anymore, and I wanted this to persist in the database. I updated the Persistence object in my appsettings.json file as follows:

    "Persistence": {
      "Schedule": "Database",
      "ScheduleParameter": "Database",
      "Variable": "Database"
    }

Next I simply deleted the Variables.ps1 file in my repo and restarted the PSU service. Sure enough, I was able to create and edit variables in the admin UI again. However, when I went to create a secret, everything is grayed out. I checked the following possible culprits:

  1. variables.ps1 is removed
  2. I set Variables to Database in the appsettings.json file
  3. I ensured that the default Database vault is the only active vault
  4. I tried setting Git from OneWay to TwoWay and disabling it
  5. I restarted the PSU service
  6. Ensured my account had the appropriate permissions

The new secret window is grayed out like so. Did I do something wrong or is this another bug?

image
image749×612 15.1 KB

EDIT: So just an update, it looks like I was able to work around this by creating the PSCredential secret in the database directly. Then refreshing the UI I could add the username/password values in the UI. Is this by design???
Actually, while I was able to create the credential this way I am getting a strange error when trying to use it this way: Error executing job: Value cannot be null. (Parameter 's')

I also updated to 5.6.13 in case this was a known bug with 5.6.12 but the behavior persists…

2

I’m using SQL as my database, but I have the ability without setting any persistence in my app settings, to store both variables and secrets in my database simply by choosing that from the popup on create.
For example, choosing this tickbox on a new variable:

image
image738×313 7.16 KB

Or are you trying to completely prevent anything being written to variables.ps1 even the definitions?

3

Thanks for the reply! I’m aware of that setting, but I was trying to isolate variables and secrets, along with schedules, in my dev server from getting pulled into prod when I git push from the dev branch to the prod branch.

My idea was to use a secret like “automationRunner” which has one credential as the value in dev, and another in prod. This is so a script can reference the same variable (automationRunner) and have different values pulled depending on which environment the script is being executed from.

Maybe that box solves that problem, but if it requires me to also have a variables.ps1 file, maybe I should just add it to the .gitignore file. What do you think?

Thanks again!

4

You could definetly do this with those checkboxes, the definition will be in the variables.ps1 but not the value, and then you can just have different values in your prod vs dev databases, thats exactly how I manage mine!

1 Like
5

Oh nice! I was overcomplicating things yet again. I’ll give that a shot!