git_pull: sanitize git_pull add-on to avoid deleting /config, fix some nits

[reynico]

"The risk of complete loss is possible." is a real thing with git_pull! I wiped out my /config folder and found that I am not alone. I did a backup just before putting my hands on git_pull, so it was innocuous for my HA install.

I added some error handling using set e so the script would stop running if an error occurred (like a misconfiguration or a connectivity problem). I also found using ~ a bit misleading when trying to set $HOME; for example, git couldn't find the ssh key when using ~ as $HOME.

Also, I decided to pass the SSH deployment key base64 encoded; otherwise, parsing the single-line SSH key would be a lot of struggle.

Last, the repo is cloned to a fresh folder called /new_config before destroying the working /config one.

[home-assistant]

Hi @reynico

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

[home-assistant]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Stale

[agners]

In general, these are some nice improvements! Thanks 👍

I think I'd suggest to undo the deployment_key_base64_encoded changes here, so we can merge the other improvements, and then tackle the deployment key changes separately.

[agners]

It is only a single log no?

Suggested change

	# Changelogs
	# Changelog

[agners]

This is not the same API. Do we actually use any of those? 🤔

See: https://developers.home-assistant.io/docs/add-ons/configuration

[reynico]

Uhm, I had many problems when trying to use hassio_api. After reading a bit, I used homeassistant_api, which worked out of the box. Given my ignorance, I thought hassio_api was replaced with homeassistant_api 😄

It's been a while, so I don't exactly recall what my issue was here, but it had to be with the validate-config function.

I can dig deeper with hassio_api and try to make it work if you want!

[agners]

Uh, this will break the setup for many people 😢

Can we not make it work with the old config option? 🤔

[agners]

Also, I decided to pass the SSH deployment key base64 encoded; otherwise, parsing the single-line SSH key would be a lot of struggle.

Uh I see. Well but this is weird too, asking the user to base64 encode their private keys yet again. The PEM (-----BEGIN... -----END...) format is already base64 encoded.

Now granted, how the multiple lines are handled here is a bit funky, even in YAML terms. E.g. instead of:

deployment_key:
  - "-----BEGIN RSA PRIVATE KEY-----"
  - MIIEowIBAAKCAQEAv3hUrCvqGZKpXQ5ofxTOuH6pYSOZDsCqPqmaGBdUzBFgauQM
  - xDEcoODGHIsWd7t9meAFqUtKXndeiKjfP0MMKsttnDohL1kb9mRvHre4VUqMsT5F
  - "..."
  - i3RUtnIHxGi1NqknIY56Hwa3id2yk7cEzvQGAAko/t6PCbe20AfmSQczs7wDNtBD
  - HgXRyIqIXHYk2+5w+N2eunURIBqCI9uWYK/r81TMR6V84R+XhtvM
  - "-----END RSA PRIVATE KEY-----"

We could use multiline YAML (note the pipe after the colon):

deployment_key: |
  -----BEGIN RSA PRIVATE KEY-----
  MIIEowIBAAKCAQEAv3hUrCvqGZKpXQ5ofxTOuH6pYSOZDsCqPqmaGBdUzBFgauQM
  xDEcoODGHIsWd7t9meAFqUtKXndeiKjfP0MMKsttnDohL1kb9mRvHre4VUqMsT5F
  ...
  i3RUtnIHxGi1NqknIY56Hwa3id2yk7cEzvQGAAko/t6PCbe20AfmSQczs7wDNtBD
  HgXRyIqIXHYk2+5w+N2eunURIBqCI9uWYK/r81TMR6V84R+XhtvM
  -----END RSA PRIVATE KEY-----

But I guess you want to address the UI representation. I am not aware that we can request multi-line string from the frontend.

So we have a bit unfortunate limitations from the UI side currently 😢

However, what we could do as a work around is using sub-option. Those are displayed as YAML fields. How about getting rid of deployment_key and deployment_key_protocol, and move to:

schema:
  deployment_identity:
    type: match(rsa|dsa|ecdsa|ed25519)
    key: str

Adjust the docs to show an example how to do the multiline string thing:

🤔

In any case. This would need a major number bump as it breaks backwards compatibility (and set the breaking_versions config).