[SOLVED] "Signing key cannot be empty" Appwrite 1.4.1 VCS_GITHUB

After creating my GitApp and configuring the .env variables and checking "Request user authorization (OAuth) during installation" in the GitApp (which is not mentioned in the docs but was suggested by @Steven to solve the "Github 404 after authorizing app" issue (https://discord.com/channels/564160730845151244/1146963381312553051) the first configured callback link is triggered by GitHub (http://[HOSTNAME_OR_IP]/v1/vcs/github/callback) but on the Appwrite side it shows:

Error 500
Signing key cannot be empty
Type
general_unknown

Did you set _APP_VCS_GITHUB_PRIVATE_KEY? if so, please DM me the ouptut of docker compose exec appwrite vars

I did send you my vars output and the comparison screenshot from the GitApp setup for _APP_VCS_GITHUB_PRIVATE_KEY

Here my logs. Basically the same state as @SenZi got into in: https://discord.com/channels/564160730845151244/1146963381312553051

"Signing key cannot be empty" Appwrite 1.4.1 VCS_GITHUB

Solved: Basically when i created the private key for the GitApp i got a .pem file automatically downloaded. The download was so fast on my machine that it was barely noticable.
So i thought the immediate displayed "SHA256:Z7oYDm2D1..." was the key.
I needed to open the .pem to copy-paste the content to my .env file. Since it is multiline it needs to be in double-quotes:

_APP_VCS_GITHUB_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAqGjCVJ7p6X6r2YQt9uJ/HvXugS+/kQoR27gPG29WZnzNuv3i
ZcudTuELlUCOITp0UhCTQ52PpysSQpoeLcq0Tg4gQFkOKrJXOojolxoqlFxI/5OI ...
-----END RSA PRIVATE KEY-----"

Is there any space afer -----BEGIN RSA PRIVATE KEY-----

copy and paste the key in exactly and it'll work

worked! finally

So ideally, you would put the key on one line because upgrades don't handle new lines well. So you can replace every newline with \n

[SOLVED] "Signing key cannot be empty" Appwrite 1.4.1 VCS_GITHUB

That was my original thought but then you presented the much simpler doublequote solution. I will probably change it when i install the next update but i fear others might have already followed the same approach/solution. Maybe a adjustment on the upgrade code may be the more elegant solution,.