I just have the one file in the root directory, I can’t remember what it was in particular but I traced it back to a few !secrets entries at the time and removed those. I’ll bet they were the ones in subdirectories. I assumed I had configured something in those components wrong, my thinking was that a top level !secrets file would load with config and sort of propagate. I had bigger fish to fry so moved on. I’ll be looking up the docs in a minute.
I’d just like to be able to easily edit and view my files while I’m at work, sharing would mean a fair bit of tidying up for me!
@rpitera - I’m not sure if I am interpreting this correctly but it looks like the !secrets resolving may have been updated, from docs…
When you start splitting your configuration into multiple files, you might end up with configuration in sub folders. Secrets will be resolved in this order:
A secrets.yaml located in the same folder as the yaml file referencing the secret,
next, parent folders will be searched for a secrets.yaml file with the secret, stopping at the folder with the main configuration.yaml,
lastly, keyring will be queried for the secret (more info below)
Sounds like you’re right, though I’m going to stick with the separate secrets files for the subs I have them in as in my mind this will resolve faster.
I’ve not tested it yet and I definitely had problems last year. Got caught up, spent the last three hours trying to work out how to push my .homeassistant directory to github or bitbucket. Might be time to put it aside and wait for the tutorial.
It’s pretty much done - I’m working with a couple of the folks here to get some suggestions and editing. I should have the PR submitted this weekend sometime.
Just one additional note: if you have several projects (hass, maybe some other code you write, your website source code, etc) it may be worthwhile to pay for a GitHub subscription. It’s $7 a month, and gives you the ability to create unlimited private repositories. So, with that, you can store your Hass configs in a private repository and not have to worry about secrets and gitignores.
Either approach is fine - just wanted to mention this other one, for those who might benefit from a private repo!
If simply having private repositories is the goal, I’ll mention that BitBucket gives you unlimited private repositories for free, and there is no change in how you commit/push etc.
I’d like to add that I followed the tutorial by @roddie here and used it successfully with bitbucket for just that reason.
Is it possible to save the git password into the update script or unlock permanently on the pi to allow pushing to the git from say an automation without the need to interact?
This can be done using ssh keys as mentioned in the tutorial. Once configured, the script will just push without prompting for username or password. This is the link in the tutorial.
One thing to keep in mind before publishing is to make sure you never checked passwords in, as they are kept in the history. If you already did that you can use BFG to clean the git history of these files.
Sorry for the late reply,i guess you already fixed it. The file ./git/config is probably owned by root and you are trying to access is as user pi. But you should set this setting globally anyway
call me stupid… but where do i create this .gitignore file??? if i create this in my git repo, i get
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.
and if i do this i get:
fatal: refusing to merge unrelated histories
and after this i do: git pull --allow-unrelated-histories
but this doesn’t seem to work…
i guess the tut is missing some details… could someone help me out?
