Github Actions UX doesn't make sense & are these Actions maintained?

[205g0]

Please correct me if I am wrong but how should we get the password from this create-branch-password-action into our local dev env? The password is redacted in the logs and, it's impossible to get this info into your local .env. So, what's the use case of this Action?

Then, this Action at planetscale/create-branch-password-action#1 faces a related issue which isn't handled.

[bmorrisondev]

@205g0 The hostname, username, and password are set as outputs for that Action step so you can pass them to downstream steps. The idea being if you need to pass these credentials to another service or environment, a subsequent step could use the info from this Action to do that. If you want to log them out, you can echo them with another step as described in the announcement blog post. The last step in the first code block does just that.

If you were trying to do this locally, the CLI would probably be a better tool to do so. I'd love to hear more about what kind of process you're trying to set up so I can provide more guidance.

Also thank you for reporting planetscale/create-branch-password-action#1 here. It made its way back to me and I'm addressing it.

[205g0]

I'd definitely advise against generating database credentials and storing them with your repository

[Edit: I've seen that we are actually on the same page at the end of your post, but still keep my following ramble, otherwise just check the bullets at the end]

Never said that. It's standard to put the db credentials into .env which is in .gitignore, hence never added to the repo.

It would be great if your CLI tool would just emit some .env (and not some CSV orJSON for dozen of langs). Still confused why the standard way isn't supported and we need to script around a JSON.

Re prod. credential these are stored in the context of the deployment provide, e.g. with CF entered manually into their dashboard, with k8s via CD.

You want to run tests on the code and need the database to do so. You could use the Actions to spin up a new branch, create creds, load data, run tests, and report back.

ok good use case

for interactive QA testing....

and the rest sounds ok-ish in theory but hell of work of setting this up. but ok

The Actions are designed for use cases where dev teams need dynamic environments that can be set up using automation. Using them within CI/CD pipelines reduces overhead required by individuals to perform these operations.

Maybe, maybe not, but the most basic use case, give me a dev branch with the creds in a KISS .env isn't supported.

Now something I did ...

Ok, before I edit my entire post again because from now, we are actually totally aligned:

• A .env is all we need
• pscale needs to emit this .env as another option as well
• Otherwise a script which creates the 1 git branch, 2 the db branch 3 the pwd and writes 4 the .env from the JSON shouldn't be too hard; Edit: or just steps 2, 3 and 4 because I don't need a new db branch on every new git branch, and maybe an flag to delete the last created branch

Should I or you write it? 🙂

[205g0]

Ok, I've thrown something together[1] but long story short, this .env creation should be integrated in pscale, why:

• JSON handling with bash is complicated or rather impossible
• node would be easy, except the part where you need to read the JSON (better than bash but still a hassle)
• TypeScript can import JSON, so a npx tsx following-script.ts my-db my-branch[1] should work

But again, why do you want the user to do all the fuzz if all we'd need is an .env. Life could be so easy.

[1] Here the script in TS:

import { spawn } from 'child_process'
import fs from 'fs'

const dbName = process.argv.at(-2)
const branchName = process.argv.at(-1)
spawn(`
  pscale bracnh swith ${branchName} --database ${dbName} --create && \
  pscale password create ${dbName} ${branchName} default-pwd -f json > temp.json
`)

// @ts-ignore
const envDb = import('temp.json')
// @ts-ignore
const envString =
  `DB_URL=mysql://${envDb.username}:${envDb.plain_text}@${envDb.access_host_url}/my-db?ssl={"rejectUnauthorized":true}`

fs.writeFile('.env', envString, (err) => {
	if (err) {
		console.error(err)
	}
	// file written successfully
})

Script still needs some lines to delete the temp.json or latter must be included in .gitignore

[bmorrisondev]

The following bash script is derived from the source of the Action in question, but does what you need provided using only bash provided jq is installed:

#!/bin/sh -l

pscale branch create $1 $2
CMDOUT=$(pscale password create $1 $2 pass-$2 -f json)

USERNAME=$(jq -n "$CMDOUT" | jq -r '.username')
PASSWORD=$(jq -n "$CMDOUT" | jq -r '.plain_text')
HOSTNAME=$(jq -n "$CMDOUT" | jq -r '.database_branch.access_host_url')
echo "DB_URL=mysql://$USERNAME:$PASSWORD@$HOSTNAME/$1?ssl={\"rejectUnauthorized\":true}" >> .env

The following snippet will set the script as executable and run it, given the script name is create-branch-and-pass.sh, the database name is recipes_db and the new branch to create is mynewbranch:

chmod +x create-branch-and-pass.sh
./create-branch-and-pass.sh recipes_db mynewbranch

I passed the request along to our engineering team, but it's not likely that it will be rolled into the CLI since different languages and environments handle secrets differently. You are also welcome to file an issue at https://github.com/planetscale/cli/issues though. Let me know if you need anything else.

[205g0]

@bmorrisondev thanks for your support and passing the request to the team. Your bash script is already super nice, terse and much better than my convoluted TS version! 🙂

[bmorrisondev]

Thanks! Someone from the engineering team also recommended giving pscale connect a try. It will create a tunnel from 127.0.0.1:3306 to your PlanetScale database branch without needing a branch-specific password. You'd need to run it each time you want to connect, but offering it as an option as it might simplify things.

More info: https://planetscale.com/docs/reference/connect