I am using macOS 11.3.1 (20E241)

# pscale auth login
Press Enter to authenticate via your browser...

Stays there and does not launch a Chrome tab.

pscale branch list prod

No branches exist in prod.

pscale connect prod

panic: runtime error: makeslice: cap out of range

goroutine 1 [running]:
github.com/planetscale/cli/pkg/cmd/connect.fetchBranch(0x1654340, 0xc00011c008, 0xc00012eb90, 0xc0001387c0, 0x13, 0x205ebdba1, 0x4, 0x15add14, 0xc0001a1b90, 0x100fe98, ...)
	/Users/abhivaidyanatha/go/github.com/cli/pkg/cmd/connect/connect.go:153 +0x12a
github.com/planetscale/cli/pkg/cmd/connect.ConnectCmd.func1(0xc0001d78c0, 0xc000111a60, 0x1, 0x1, 0x0, 0x0)
	/Users/abhivaidyanatha/go/github.com/cli/pkg/cmd/connect/connect.go:64 +0x78f
github.com/spf13/cobra.(*Command).execute(0xc0001d78c0, 0xc0001120b0, 0x1, 0x1, 0xc0001d78c0, 0xc0001120b0)
	/Users/abhivaidyanatha/go/github.com/cli/vendor/github.com/spf13/cobra/command.go:850 +0x47c
github.com/spf13/cobra.(*Command).ExecuteC(0x1912660, 0xc0001a1f48, 0x1, 0x1)
	/Users/abhivaidyanatha/go/github.com/cli/vendor/github.com/spf13/cobra/command.go:958 +0x375
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/abhivaidyanatha/go/github.com/cli/vendor/github.com/spf13/cobra/command.go:895
github.com/planetscale/cli/pkg/cmd.Execute(0xffffffff, 0xc000100058)
	/Users/abhivaidyanatha/go/github.com/cli/pkg/cmd/root.go:93 +0x7ad
main.main()
	/Users/abhivaidyanatha/go/github.com/cli/cmd/pscale/main.go:10 +0x25

pscale shell creates a history file by default in $HOME/.pscale/history. While this is not an error, I think the CLI should respect an OS (or the user’s) XDG base directory settings. The history file should be placed under XDG_DATA_HOME: on Mac, it should go under ~/Library/Application \Support/.pscale and on most Unix-like operating systems, it should go under $HOME/.local/share.

I’d be happy to make a PR if you guys agree with the change.

The way we are currently naming pscale packages each release is not done in a way that would allow someone to write code to pull whatever the latest version of say pscale_linux_386.deb. The package names all have the version number in the name and thus are all unique.

If we kept the package names the same across releases and just changed the release tag then we should be able to always get the latest version of the package using something like;

wget https://github.com/planetscale/cli/releases/latest/pscale_linux_386.deb

If we want people to build Docker images or sidecar containers we should make it easy for them to pull the latest version of pscale, without having to update their dockerfile each new release.

Issue statement

Greetings.

I'm trying to get into the shell of the main branch and the command pscale shell <database> main started throwing

Error: signal: segmentation fault (core dumped)

Although, the command seem to work fine with other branches.

For some context, I'm using the CLI inside a newly spun container based on the Ubuntu 20:04 image. Authentication and deploy request were the commands made prior to this error and those were successful.

Screenshot

Version

pscale version 0.68.0 (build date: 2021-08-19T11:23:27Z commit: 6c41383)

Problem:

Running a command like this silently continues to run (note that branch foo doesn't exist):

pscale connect prod fooo
Secure connection to databases prod and branch fooo is established!.

Local address to connect your application: 127.0.0.1:3307 (press ctrl-c to quit)^C% 

However running it in verbose mode, we can see that it failed to fetch the certs:

$ pscale connect prod fooo --v
Secure connection to databases prod and branch fooo is established!.

Local address to connect your application: 127.0.0.1:3307 (press ctrl-c to quit)

2021-01-30T11:08:11.352+0300    ERROR   proxy/client.go:106     couldn't retrieve TLS certificate for the client        {"app": "sql-proxy-client", "error": "couldn't retrieve certs from cert source: Unable to find database branch for certificate"}
github.com/planetscale/sql-proxy/proxy.NewClient.func1

Solution:

Don't fetch the certs in background in the sql-proxy library: https://github.com/planetscale/sql-proxy/blob/main/proxy/client.go#L103. Removing the go keyword, will make sure the certs are fetched first and let's us see any errors.

On my personal organization gordon I have attempted to create a branch off of main of my newly made database. At the time of writing I am using the most up to date pscale version

pscale version 0.5.0 (build date: 2021-03-22T14:37:06Z commit: e2083b5)

I attempted to create a branch off of main called candidate

pscale branch main candidate
Error: Not Found

OS: Ubuntu

note - I manually created the branch candidate after filing this issue in case someone investigates my org and see it there.

I have tried the way to launch my server along with the connect command with an --execute option but have got the following error. Oddly, it also asks which database branch I would connect even though I've specified it in the command line.

As this from the example does not work basically I cannot run any commands. Is there something wrong with my approach?

C:\Users\apricot\src\kemakino\3RFM-ITS-Davis\publication-manager\server>pscale connect publication next --execute 'node app.js'  
? Select a branch to connect to: next
Secure connection to database publication and branch next is established!.      

Local address to connect your application: 127.0.0.1:3306 (press ctrl-c to quit)
Error: failed to parse command, not running: invalid command line string

Installed the pscale cli, and getting a blank error when executing 'pscale auth login'

pscale database create -w

Error: <name> is missing

Right now if you try to connect to a database that doesnt exist on your active org you'll get:

$ pscale connect does-not-exist
Error: Not Found

This caused some confusion on my team when this command was being run in a script and we couldn't tell where it was coming from.

It would be much better if it said something like:

Error: Database "does-not-exist" was not found in the current selected org "personalaccount"

You may want to run one of the following commands:

- pscale database list
- pscale org switch

My apologies if this is another environmental issue on my side! But figured I'd document it either way.

When I press the "up" arrow key to go back through the CLI history, the first key press returns the previous command. The second key press:

• returns the first 19 characters of the previous command. Or, if the previous command is shorter than 19 characters, it returns the previous command and pads empty spaces through the 19th character.
• begins the second-previous command in the 20th column

When I try to delete the line, I can't delete those first 19 characters. If I type a new command and hit "enter", the new command works. So, I think it's just a strange visual thing.

I don't experience this in the general mysql CLI.

My ~/.pscale/history/croaky.example.main file looks like this:

_HiStOrY_V2_
show\040tables;
describe\040users;
show\040tables;
exit
show\040tables;
describe\040users;
exit
describe\040reminders;
select\040*\040from\040reminders;

MySQL appears to be linked to libedit/editline:

% otool -L "$(which mysql)"
/opt/homebrew/opt/mysql-client/bin/mysql:
	/usr/lib/libedit.3.dylib (compatibility version 2.0.0, current version 3.0.0)
	/opt/homebrew/opt/[email protected]/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/opt/homebrew/opt/[email protected]/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

I have no overrides in ~/.editrc.

DATABASE_URL is a good default assumption for connect --execute, but sometimes it would be hand to be able to define a different ENV var name es the application is already using a different one, similar to --execute-protocol 'mysql'.

I suggest --execute-env so this becomes possible: --execute-env 'PLANETSCALE_DB_URL'.

Hey there,

I tried to run pscale shell <database> <branch> but I keep getting:

Error: couldn't find the 'mysql' command-line tool required to run this command. To install, follow the instructions: https://dev.mysql.com/doc/refman/8.0/en/windows-installation.html

I installed the Developer Default bundle. Running msqlsh --version returns:

C:\Program Files\MySQL\MySQL Shell 8.0\bin\mysqlsh.exe Ver 8.0.26 for Win64 on x86_64 - for MySQL 8.0.26 (MySQL Community Server (GPL))

But I still get there error above. Would be awesome if somebody could explain which package is exactly needed on a windows machine.

This was brought to my attention by one of our users.

Context:

While you can currently opt in to our new Rewind feature, and both revert a deploy request, or say "No thanks, I won't need to revert" within the PlanetScale Web UI, it does not appear that you can do so yet from the CLI.

It appears that we would likely need a new subcommand for rewind, possibly taking a format similar to this:

pscale deploy-request rewind <DATABASE_NAME> <DR_NUMBER>

Separately, for the "No thanks, I won't need to revert" option, I could see that as being part of the close subcommand with a --force flag perhaps (or something named differently that allows the meaning to come across correctly)

pscale deploy-request close <DATABASE_NAME> <DR_NUMBER> --force

Another approach might be to have it be a part of the deploy subcommand instead which would allow the ability to rewind be skipped entirely if used:

pscale deploy-request deploy <DATABASE_NAME> <DR_NUMBER> --skip-rewind

I'm sure there's plenty of different ways to approach it so those are just two I thought of quickly on my end.

This item would be related as well to #479 the desire to have an auto-deploy or auto-deploy-and-close option added in might get more complicated with the addition of Rewind above since the Rewind related options above may need to be integrated into that work too.

pscale connect test --org test_org --service-token-name #### --service-token ####

when I connect via auth login, it works.. but I would like to connect to my base using service token.. I did all authorizations and put on service token name the name that I gave and the service token Id as well..

Error: Not Found

Same problem using --service-token-id..

Error: database test and branch main does not exist in organization test_org

Steps taken:

Created account and database instance, connected to it, made "main" the production branch, created a branch with a table and 1 entry, promoted it.
Ran pscale branch create <mydatabasename> <newbranchname>
Ran pscale shell Commandline output was Error: database branch is not ready yet`

Instead I would have expected to have a message please wait and the command line client not return with exitcode != 0, instead, connect to the DB as soon as the branch creation completes

Didn't have mysql commandline util installed

Error output was

Error: couldn't find the 'mysql' command-line tool required to run this command.
To install, follow the instructions: https://docs.planetscale.com/reference/planetscale-environment-setup#linux-instructions

Link does not work

++ brew install planetscale/tap/pscale
==> Tapping planetscale/tap
Cloning into '/home/linuxbrew/.linuxbrew/Homebrew/Library/Taps/planetscale/homebrew-tap'...
Tapped 2 formulae (15 files, 141.5KB).
==> Installing pscale from planetscale/tap
==> Downloading planetscale/[email protected] pscale_0.51.12-rc1_linux_amd64.tar.gz (download)
curl: (22) The requested URL returned error: 404 
Error: Failed to download resource "pscale"
Download failed: planetscale/[email protected] pscale_0.51.12-rc1_linux_amd64.tar.gz (download)
Warning: Attempt 1 failed. Reason: Child_process exited with error code 1

via https://github.com/prisma/e2e-tests/runs/3030256153?check_suite_focus=true

There might be a security issue for why this isn't done right now, but I feel like it would be really cool if I didn't have to view the UI to get my connection string. Then I could just instantly connect with pscale connect after bringing it up.

Hey everyone! It would be absolutely superb if the CLI would wait for branches to be ready rather than exiting completely in the following scenario:

Def have the mysql client installed with brew install mysql-client, but when I do pscale shell testdb main is gives me this error:

Error: couldn't find the 'mysql' client required to run this command.
To install, run: brew install mysql-client

Reinstalling mysql-client didn’t work either.

For convenience, I have a ~/.my.cnf file configured to connect to my development MySQL instance -- this lets me run mysql with no arguments.

This seems to break pscale shell, which spits out this error:

ERROR 1105 (HY000): unknown database '<database name>'
Error: exit status 1

I suspect pscale isn't specifying the database to connect to when it invokes the MySQL CLI. Is that something you could fix? It would make the local workflow a lot nicer. Thanks for your consideration. :)

Hi all,

I am trying to connect from docker environment by using service token approach but I think it is broken. Here is the command I am trying to connect:

docker run \
          -e PLANETSCALE_SERVICE_TOKEN=yyyy \
          -e PLANETSCALE_SERVICE_TOKEN_ID=xxxx \
          -e PLANETSCALE_SERVICE_TOKEN_NAME=zzzz \
          -e HOME=/tmp -v $HOME/.config/planetscale:/tmp/.config/planetscale \
          -e PSCALE_ALLOW_NONINTERACTIVE_SHELL=true --user $(id -u):$(id -g) --rm -i $tty planetscale/pscale:${PSCALE_VERSION:-"latest"} \
          connect mydb prod --org=startupheroes --port=3309

It prints database mydb and branch prod does not exist in organization startupheroes

@fatih I think it is related to planetscale/planetscale-go#111 as well.

Thanks

I want to try out the PlanetScale MySQL service in my AWS Lambda functions. How do I go about it?

Problem description

By default, pscale connect binds to 127.0.0.1:

# starting up docker container
docker run -e PLANETSCALE_SERVICE_TOKEN -e PLANETSCALE_SERVICE_TOKEN_NAME -e $PLANETSCALE_ORG -e $PLANETSCALE_BRANCH -e $PLANETSCALE_DB --rm -it  -p 3306:3306  planetscale/pscale:latest connect $PLANETSCALE_DB $PLANETSCALE_BRANCH --org $PLANETSCALE_ORG
Secure connection to database brandnewdb and branch mybranch is established!.

Local address to connect your application: 127.0.0.1:3306 (press ctrl-c to quit)

If pscale was running in a Docker container, the loopback device connected to 127.0.0.1 will not accept any connections from outside the container and attempts to do so will result in an error message:

localcomputer# mysql -h 127.0.0.1
ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

Posible workaround

pscale has a --host parameter to bind to a different interface, but this would require to know the host IP in advance before running the docker run command. A workaround would be to use a different entry point for the docker image and find out the host ip programmatically:

docker run -e PLANETSCALE_SERVICE_TOKEN=$PLANETSCALE_SERVICE_TOKEN -e PLANETSCALE_SERVICE_TOKEN_NAME -e PLANETSCALE_BRANCH -e PLANETSCALE_ORG -e PLANETSCALE_DB --rm -it -p 3306:3306/tcp --entrypoint '/bin/sh' planetscale/pscale:latest -c 'pscale connect --host `hostname -i | awk "{print $1}"` $PLANETSCALE_DB $PLANETSCALE_BRANCH --org $PLANETSCALE_ORG'

Secure connection to database brandnewdb and branch mybranch is established!.

Local address to connect your application: 172.17.0.2:3306 (press ctrl-c to quit)

In that case, connections from outside the container work:

mysql -h 127.0.0.1 -P 3306
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3277
Server version: 8.0.23-vitess 
...

The same approach (i.e. use a different Docker entry point) could be used for docker-compose or a Kubernetes based example, as shown in this gist.

However, without changing the entrypoint, it does seem very hard to use pscale connect in a container based environment.

Possible solutions

a) document workaround
b) introduce an option for pscale connect like --network-interface where you can specify something like eth0 to use that device instead of the loopback device (lo)
c) introduce an option like --bind-to-hostname to bind against the first ip returned by hostname -i
d) your ideas here

Now that we have a pscale branch switch command, it would be maybe better to move the current switch command under the pscale org subcommand. This way the commands would more consistent and we could use pscale org for other use cases as well in the future.

Currently if the auth token has expired, we show

{"error":"invalid_token","error_description":"The access token is invalid","state":"unauthorized"}

This could be better and give instructions on how to fix it. Such as: run pscale auth login to refresh your token.

Hi

I am trying to integrate the Planetscale CLI with Drone CI & CD. I have created a service token for my organization, but I just cannot get it to work.

Could you give me a hint on how to use service tokens with the CLI as it is not documented in the docs.

Currently, I try to create a shell wrapper function and alias it to the pscale command such that I do not need to add the service token to any subsequent invocations.

function pscale_wrapper () {
    sleep 4
    pscale "$@" \
        --org ${PSCALE_ORG} \
        --service-token ${PSCALE_SERVICE_TOKEN} \
        --service-token-name ${PSCALE_SERVICE_TOKEN_NAME}
}

alias pscale="pscale_wrapper"

This leads me to the following error in Drone:

Error: not authenticated yet. Please run 'pscale auth login' or create a service token with 'pscale service-token create'

Thank you in advance!

Sorry, I didn’t see a PlanetScale.com repo, so adding this suggestion here:

For Vercel, the certificate string is different, so I would propose adding an option in the dropdown for Vercel as well.

For Vercel it’s:
?sslmode=require&sslcert=/etc/pki/tls/certs/ca-bundle.crt

Observation

Update: Turns out, the problem only exists if a data base was created with the tutorial data and should probably rather handled with a remark in the documentation.

The examples in the documentation and the express example app on how to use connect command with --execute currently fail with "unknown database" errors:

pscale connect monalisa main --execute 'node app.js'
Secure connection to database monalisa and branch main is established!.

Local address to connect your application: 127.0.0.1:3306 (press ctrl-c to quit)
Example app listening at http://localhost:3000
/home/codespace/express-example/node_modules/mysql/lib/protocol/Parser.js:437
      throw err; // Rethrow non-MySQL errors
      ^

Error: ER_UNKNOWN_ERROR: unknown database 'monalisa'
    at Handshake.Sequence._packetToError (/home/codespace/express-example/node_modules/mysql/lib/protocol/sequences/Sequence.js:47:14)
    at Handshake.ErrorPacket (/home/codespace/express-example/node_modules/mysql/lib/protocol/sequences/Handshake.js:123:18)
    at Protocol._parsePacket (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:291:23)
    at Parser._parsePacket (/home/codespace/express-example/node_modules/mysql/lib/protocol/Parser.js:433:10)
    at Parser.write (/home/codespace/express-example/node_modules/mysql/lib/protocol/Parser.js:43:10)
    at Protocol.write (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:38:16)
    at Socket.<anonymous> (/home/codespace/express-example/node_modules/mysql/lib/Connection.js:88:28)
    at Socket.<anonymous> (/home/codespace/express-example/node_modules/mysql/lib/Connection.js:526:10)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:309:12)
    --------------------
    at Protocol._enqueue (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:144:48)
    at Protocol.handshake (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:51:23)
    at Connection.connect (/home/codespace/express-example/node_modules/mysql/lib/Connection.js:116:18)
    at Object.<anonymous> (/home/codespace/express-example/app.js:8:12)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
    at internal/main/run_main_module.js:17:47
Emitted 'error' event on Connection instance at:
    at Connection._handleProtocolError (/home/codespace/express-example/node_modules/mysql/lib/Connection.js:423:8)
    at Protocol.emit (events.js:315:20)
    at Protocol._delegateError (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:398:10)
    at Handshake.<anonymous> (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:153:12)
    at Handshake.emit (events.js:315:20)
    at Handshake.Sequence.end (/home/codespace/express-example/node_modules/mysql/lib/protocol/sequences/Sequence.js:78:12)
    at Handshake.ErrorPacket (/home/codespace/express-example/node_modules/mysql/lib/protocol/sequences/Handshake.js:125:8)
    at Protocol._parsePacket (/home/codespace/express-example/node_modules/mysql/lib/protocol/Protocol.js:291:23)
    at Parser._parsePacket (/home/codespace/express-example/node_modules/mysql/lib/protocol/Parser.js:433:10)
    at Parser.write (/home/codespace/express-example/node_modules/mysql/lib/protocol/Parser.js:43:10) {
  code: 'ER_UNKNOWN_ERROR',
  errno: 1105,
  sqlMessage: "unknown database 'monalisa'",
  sqlState: 'HY000',
  fatal: true
}
Error: running command with --execute has failed: exit status 1

Analysis

• pscale connect exposes the DB it connects to as default DB (without the DB name in the path):

codespace ➜ /workspaces/cli/cmd/pscale (main ✗) $ pscale connect monalisa main
Secure connection to database monalisa and branch main is established!.

Local address to connect your application: 127.0.0.1:3306 (press ctrl-c to quit)

mysql -u root -P 3306 -h 127.0.0.1
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9075
Server version: 8.0.23-vitess Version: 11.0.0-SNAPSHOT (Git revision 13dadf3 branch 'main') built on Mon Jun  7 17:05:20 UTC 2021 by vitess@buildkitsandbox using go1.15.6 linux/amd64

...

mysql> describe reminders;
+------------+---------------+------+-----+----------------------+-------------------+
| Field      | Type          | Null | Key | Default              | Extra             |
+------------+---------------+------+-----+----------------------+-------------------+
| id         | bigint        | NO   | PRI | NULL                 | auto_increment    |
| body       | varchar(1024) | NO   |     | NULL                 |                   |
| created_at | datetime(6)   | NO   |     | CURRENT_TIMESTAMP(6) | DEFAULT_GENERATED |
| updated_at | datetime(6)   | NO   |     | CURRENT_TIMESTAMP(6) | DEFAULT_GENERATED |
| is_done    | tinyint(1)    | NO   |     | 0                    |                   |
+------------+---------------+------+-----+----------------------+-------------------+
5 rows in set (0.09 sec)

• however, pscale connect --execute sets the DATABASE_URL env variable to a value that contains the DB name in its path, in the example ☝️ , it would be set to mysql2://[email protected]:3306/monalisa, although in order to connect properly to the way, the DB was exposed, the value would actually need to be mysql2://[email protected]:3306/ if the examples in the docs or the way pscale connect exposes the DB should stay as is.

Possible solution

Created #307 that will not set the DB name as part of DATABASE_URL. If the DATABASE_URL should stay as is, pscale connect would need to expose the DB it connects to with a different path.

The user has to install the completion scripts for various shells manually. To automate it, let's include the completions as part of our archives/homebrew recipes, etc... That way, the user will automatically receive the completions and don't have to maintain them manually.

Here is an example of how the goreleaser project does it by using goreleaser itself: https://github.com/goreleaser/goreleaser/blob/master/.goreleaser.yml

Hello, any change to provide Linux arm32 v7 release ?

thnx

Trying to run pscale shell <database> <branch> I receive the error:

➜  ~ pscale shell thunks main                  
/usr/bin/mysql: unknown option --defaults-extra-file
Error: exit status 1

pscale version:

➜  ~ pscale --version
pscale version 0.39.0 (build date: 2021-05-24T12:03:51Z commit: b321aeb)

mysql version:

➜  ~ mysql --version
mysql   Ver 8.0.25 for Linux on x86_64 - for MySQL 8.0.25 (MySQL Community Server (GPL))

Running on:

➜  ~ uname -srm
Linux 5.11.14-1-MANJARO x86_64

It does work if I use pscale connect and then start the mysql shell from the command line and pass in the proper args.

Attempting to install on MacOS 12 on an M1 Macbook Air.

Recieve the following error when I ran "brew install planetscale/tap/pscale"

==> Tapping planetscale/tap Cloning into '/opt/homebrew/Library/Taps/planetscale/homebrew-tap'... remote: Enumerating objects: 410, done. remote: Counting objects: 100% (410/410), done. remote: Compressing objects: 100% (396/396), done. remote: Total 410 (delta 139), reused 28 (delta 8), pack-reused 0 Receiving objects: 100% (410/410), 67.68 KiB | 1.93 MiB/s, done. Resolving deltas: 100% (139/139), done. Error: Invalid formula: /opt/homebrew/Library/Taps/planetscale/homebrew-tap/Formula/pscale-proxy.rb formulae require at least a URL Error: Cannot tap planetscale/tap: invalid syntax in tap!

Happy to try any troubleshooting steps you think might help?

Hello,

How can i use pscale cli? I can't find pscale cli usage documentation. I can find CLI option but needs documentation.

The current production deployment process advises wrapping an existing application or executable in the pscale client. This becomes problematic for the following reasons:

1. Not all existing apps are keyed to look for the DATABASE_URL env variable in their configurations.
2. Not all existing apps are directly managed (some are packaged upstream and are pulled into the same pod as the application) and so require repackaging to wrap in the pscale binary.
3. For larger scale deployments where processing cycles or space are in short supply, running an extra 9Mb process alongside each application could be a non-starter.
4. For other, uptime sensitive deployments, running the primary application as a sub-process of pscale could be a non-starter.

It is with these problems in mind that I request a standalone container image blessed by planetscale that takes the following env vars:

PLANETSCALE_ORG: <ORG_NAME>
PLANETSCALE_SERVICE_TOKEN_NAME: <SERVICE_TOKEN_NAME>
PLANETSCALE_SERVICE_TOKEN: <SERVICE_TOKEN>
PLANETSCALE_PORT: <EXPOSED_PORT>
PLANETSCALE_DATABASE: <DATABASE_NAME>
PLANETSCALE_BRANCH: <DATABASE_BRANCH>

And exposes the resulting forwarding service on PLANESCALE_PORT. This would solve all four of the problems outlined above and is in fact what I ended up deploying to test planetscale. I hope this helps, I'm looking forward to playing with your product.

0.40.0 added the great feature that connect ends when the command in --execute ends. Unfortunately pscale connect still exits with status code 1, which a test runner or CI system of course interpret as a failure: https://github.com/prisma/e2e-tests/pull/1700/checks?check_run_id=2669053383#step:5:134

It would be great if the CLI could pick up the exit code of the wrapped command, and bubble that up and exit pscale connect with that.

The Windows CLI throws the following error when port 3306 is already in use:

C:\Users\Jan\Documents\throwaway\planetscale  ([email protected])
λ pscale connect fk-test foo
Error: error net.Listen: listen tcp 127.0.0.1:3306: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

You could either have a more descriptive error message, or automatically use a different port that is available.

Hello! I was attempting to setup the pscale CLI within a GitHub Codespace, and encountered a slight blocker. I can download and install the binary, but true automation would mean also logging in with a Service/API token automatically. Unfortunately, that doesn't seem possible, given:

I would assume that by passing a --service-token to pscale auth login, it would use the token without requiring an additional step. Could there be a flag to bypass that step? I have no idea how complicated that'd be from the other end.

My setup

In any case, here's my whole setup:

.devcontainer.json

{
  "onCreateCommand": "script/on-codespace-create"
}

script/on-codespace-create

#!/bin/sh

# Download PlanetScale CLI
curl -s https://api.github.com/repos/planetscale/cli/releases/latest \
  | grep browser_download_url \
  | grep "linux_amd64.deb" \
  | cut -d : -f 2,3 \
  | tr -d \" \
  | wget -qi - -P ~

# Install it
sudo dpkg -i ~/pscale_*_linux_amd64.deb

Ideal solution

Ideally, I'd like to do this:

# ...
# Install it
sudo dpkg -i ~/pscale_*_linux_amd64.deb

# Login using the Service token environment variable
pscale auth login --service-token=$PSCALE_SERVICE_TOKEN

That way I could either immediately start using pscale, or even connect to a dev database automatically. Right now that prompts like this (which of course works fine, but can't be fully automated):

Failed to open a browser: exec: "xdg-open": executable file not found in $PATH

Confirmation Code: <REDACTED>

If something goes wrong, copy and paste this URL into your browser: https://auth.planetscale.com/oauth/device?user_code=<REDACTED>

⠧ Waiting for confirmation... 

_{Hi @mscoutermarsh 🥺 👉 👈}

Are there any examples of using this within a Github Action? Our team is looking at switching to Planetscale, but needs to accomplish the following with our preview urls in Vercel:

1. Not step on each other's toes in preview environment
2. Deterministically seed a few items into the database before our Next.js repo statically generates a few pages.

I can provide our current Github Action for accomplishing this with a Postgres db if that would be helpful.

This pscale password create db-name branch-name password-name -f csv produces the following:

Error: cannot use password.PasswordWithPlainText, only slice or array supported

The password is created and the problem seems to be related with CVS as the output. Works well with human or json formats.

Might be related to #166

pscale --version
pscale version 0.81.0 (build date: 2021-10-19T17:44:13Z commit: da1aec4)

trying to dump a test Planetscale database into local files with pscale CLI.

it appears that no matter what options i give to "pscale database dump ... " i get a directory full of .sql files. example:

"pscale database dump myDatabase myDatabaseBranch -output csv --format csv" --> a dir called "csv" full of .sql files.

"pscale database dump myDatabase myDatabaseBranch -output json --format json" --> a dir called "json" full of .sql files.

"pscale database dump myDatabase myDatabaseBranch -output human --format human" --> a dir called "human" full of .sql files.

am i missing something here? i hardly consider myself an expert, but this seems to not work as intended/as the cli help describes.

Scenario

• I'm running pscale 0.89 on Ubuntu Linux 64-bit on Raspberry Pi 3 B+ (ARM64)
• I'm running pscale inside a Docker container, using the Ubuntu base image (docker run -it ubuntu:latest)
• I promoted the main branch to production
• I used "pscale shell" to connect to the production branch
• I received an error (see below)

Actual Result

root@f8ef97c5103b:/# pscale branch promote trevor main
Branch main in trevor was successfully promoted.
root@f8ef97c5103b:/# pscale shell trevor main
Error: signal: segmentation fault (core dumped)

However, pscale shell works perfectly fine connecting to a dev branch.

root@f8ef97c5103b:/# pscale shell trevor dev1
trevor/dev1>

Expected Result

1. Successful connection to main (production) branch
2. Error indicating that connecting to production branches is unsupported

When running pscale auth login on WSL2 - Ubuntu, there is no output, nor redirect to any new windows for authentication.
Output of the command only shows up after I cancel the execution of the command (by pressing ctrl + c) then it outputs (probably) the expected things:

pscale auth login
^CFailed to open a browser: signal: interrupt

Confirmation Code: YMHOSZCP

If something goes wrong, copy and paste this URL into your browser: https://auth.planetscale.com/oauth/device?user_code=YMHOSZCP

Error: error performing http request: Post "https://auth.planetscale.com/oauth/token": context canceled

When I do try the provided URL it does surprisingly redirect me to the confirmation page with the code, where I can accept it.
When I do, it does go through, but obviously this token is not active anymore so the auth in the pscale cli does not register me as logged in.

I did upgrade all the packages in ubuntu
I downloaded and installed the newest release of the cli
I gave it quite a long time to run

Hi Team,

My headless env didn't have xdg-open, nor any browsers installed. It would be good if also the screen didn't fill up with W's while waiting.. as it kills the useful information - i'm sure its due to my very minimal install. Some pre-req packages might be need? I had to install xdg-utils at a min.

Took me a little bit to capture the information and get it working. Ended up starting up a screen sessions with logging to capture the output.

less -r screenlog 
# pscale auth loigin
/usr/bin/xdg-open: line 862: www-browser: command not found
/usr/bin/xdg-open: line 862: links2: command not found
/usr/bin/xdg-open: line 862: elinks: command not found
/usr/bin/xdg-open: line 862: links: command not found

Confirmation Code: xxxxxx

If something goes wrong, copy and paste this URL into your browser: https://auth.planetscale.com/oauth/device?user_code=xxxxxx

Successfully logged in.

normal less and it actually flls the screen with W's

ESCkroot@ei2:~ESC\[root@ei2 ~]# pscale auth loiESC[ESC[Kgin
/usr/bin/xdg-open: line 862: www-browser: command not found
/usr/bin/xdg-open: line 862: links2: command not found
/usr/bin/xdg-open: line 862: elinks: command not found
/usr/bin/xdg-open: line 862: links: command not found
ESC[1m
Confirmation Code: ESC[0mESC[1;32mxxxxxxx
ESC[0m
If something goes wrong, copy and paste this URL into your browser: ESC[1mhttps://auth.planetscale.com/oauth/device?user_code=xxxxxxxESC[0m

^MESC[K^MESC[1;32m⠋ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠙ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠹ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠸ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠼ESC[0m Waiting ^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠴ESC[0m^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠦ESC[0m Waiting for confirma^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K
^MESC[K^MESC[1;32m⠧ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠇ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠏ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠋ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠙ESC[0m Waiting ^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠹ESC[0m^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠸ESC[0m Waiting for confirma^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K
^MESC[K^MESC[1;32m⠼ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠴ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠦ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠧ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠇ESC[0m Waiting ^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠏ESC[0m^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠋ESC[0m Waiting for confirma^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K
^MESC[K^MESC[1;32m⠙ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠹ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠸ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠼ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠴ESC[0m Waiting ^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠦ESC[0m^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠧ESC[0m Waiting for confirma^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K
^MESC[K^MESC[1;32m⠇ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠏ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠋ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠙ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠹ESC[0m Waiting ^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠸ESC[0m^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠼ESC[0m Waiting for confirma^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K
^MESC[K^MESC[1;32m⠴ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠦ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠧ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠇ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠏ESC[0m Waiting ^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠋ESC[0m^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠙ESC[0m Waiting for confirma^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K
^MESC[K^MESC[1;32m⠹ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠸ESC[0m W^H^H^H^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠼ESC[0m Waiting for conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HW^HESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^M^MESC[1;32m⠴ESC[ESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[KESC[K^MESC[K^MESC[1;32m⠦ESC[0m Waiting 

Over the past year I've been connecting to my db via pscale connect rolldeep dev --port 3309, then logging in via a browser to authenticate. This morning was the first time I've used the cli in about 3 weeks and am getting this message:

$ pscale connect rolldeep dev --port 3309
Error: internal error, response body doesn't match error type signature with the following output:

{"error":"invalid_token","error_description":"The access token is invalid","state":"unauthorized"}

Looking in the documentation, it doesn't seem like I am using access tokens. Has anything changed with auth via the cli?

Many thanks for maintaining a fantastic project!

$ pscale --version
pscale version 0.94.0 (build date: 2022-04-25T16:39:10Z commit: baf5baf)

Context shared by user:

Right now in order to do a deploy request via CLI you need to do it in 3 calls : create + deploy + close. It would be a nice addition to do so in a single CLI call that would do those 3 steps. And just report errors if the deploy couldn't be done for some reason.

In the meantime I'm having to script these steps + having to parse the create output to get the DR_number to use in the next 2 calls...that's a lot of unwarranted complexity.

The current list of commands the user needs to complete looks something like this:

pscale deploy-request create <DATABASE_NAME> <BRANCH_NAME> --deploy-to <BRANCH_NAME>
pscale deploy-request deploy <DATABASE_NAME> <DR_NUMBER>
pscale deploy-request show <DATABASE_NAME> <DR_NUMBER>
pscale deploy-request close <DATABASE_NAME> <DR_NUMBER>

The show in there is for the user to be able to check whether the deploy is complete.

Looking at the current structure of the subcommands in our docs:
https://docs.planetscale.com/reference/deploy-request#available-sub-commands

It seemed like one of the simpler ways to possibly make this functionality available to users might be to add a flag as part of the create step of the process:

pscale deploy-request create <DATABASE_NAME> <BRANCH_NAME> --deploy-to <BRANCH_NAME> --auto-deploy

Although I wasn't sure if something like --auto-deploy should include the close step or not. If not, then a secondary flag that also includes that step might be handy to have as well such as:

pscale deploy-request create <DATABASE_NAME> <BRANCH_NAME> --deploy-to <BRANCH_NAME> --auto-deploy-and-close

Lastly, the user also shared the following:

The call would be synchronous (ie. wait for the deploy to be complete). If all went well the call would simply exit.
Of course if an issue prevents the deploy from completing then it would have to warn the user that deploy-request XX is in progress along with the appropriate error message and it's then the user's responsibility to finish off the job manually, potentially close the request and try again, etc.

Hopefully these are enough details to help guide the potential addition of this particular request.

Overview

I'm trying to use the CLI to close a deploy request. It seems to correctly close the deploy request but always returns non zero error with this message: Error: Actor must exist, regardless of using CLI or docker image.

Version 0.93.0

Details

Here's how I use it:

$ PLANETSCALE_SERVICE_TOKEN=<token> \
  PLANETSCALE_SERVICE_TOKEN_NAME=<token_name> \
  pscale deploy-request close <database_name> <deploy_request_number> --org <org_name>

It'll show return this in the terminal:

Error: Actor must exist

Here's what it looks like in the UI, note how it says "Ghost" :

Merge events also say "Ghost" as the actor and don't throw this error. Not sure if this is intended.

Expected result

pscale deploy-request close should not throw non zero errors if the deploy request is closed.