As of version 0.29.0, the env-file directive doesn't appear to be working

[2q2code]

profiles:

  # base_profile
  base_profile:
    env-file: "/etc/resticprofile/.env"

In this snippet, I have included the section of my profiles.yaml file that creates a base_profile that all other profiles inherit. The dotenv file contains the username and password for the restic REST server, and a list of databases to be backed up. This file is not loaded for child processes and it is not loaded (unsure if it is meant to) for resticprofile itself. In order to work around this, I am declaring each environment variable also using the env directive within the profiles.yaml file for the moment, but this won't work for the databases, as they generate dynamic profiles based on the environment, so I will need to work around this some other way. In systemd, a unit that generates the environment is called first and this works fine, but for direct terminal usage, I will need to write a script.

[creativeprojects]

The env file should work, I'm using it on one of my configs 🤔

Please note resticprofile won't complain if it cannot find/open the file. (Ideally we should show a warning but it interferes with the internal environment file used to transfer environment values between commands <- we need to fix that)

Could it be some permission issues?

[2q2code]

Just checked. I don't think so. I run resticprofile as user restic (sudo -u restic resticprofile), and that user is the owner of both the .env file and the profiles.yaml file, and all directories in the path have x permission bit set for all users and the .env file itself has rw for owner and r for all else (not what it WILL be, but as it is).

[2q2code]

Weirdly, I just ran resticprofile as current user, after sourcing the env file manually (and testing) and it still isn't picking up the environment variables with unchanged yaml. I will remove the env things from the yaml and test next. To confirm what I am testing against, is the syntax for templating within yaml with or without the leading #?

[creativeprojects]

To confirm what I am testing against, is the syntax for templating within yaml with or without the leading #?

I'm not too sure what you mean.

You can check the resulting configuration with the --trace flag on the command line. (it could be displayed multiple times depending on the number of steps to build it)

For example:

resticprofile --trace show

[2q2code]

Okay, so I run zsh, and I just learned there is a difference between a zsh variable and an environment variable. My .env files looks like this:

PG_DATABASES="db_a db_b db_c db_d db_infinitum"
RESTIC_REST_USERNAME=username
RESTIC_REST_PASSWORD=password

Now if I run source .env, the variables will be accessible in any zsh executed thing, but they do NOT appear if I call /usr/bin/env. I have a feeling that if I used this file in a systemd service unit (i.e. EnvironmentFile=), it would work, but I don't think the RESTIC_REST_... variables are being picked up by resticprofile when they are referenced using the absolute path of the .env file (env-file:). I realise that the databases variable is unfortunately too late to be declared here, as it needs to be in the environment before resticprofile is called! I think if I export these vars then try running resticprofile, the dynamic profile building will work (yes, the # is required in the templating part - # {{ template here }} ) for that. I will give it a go.

[creativeprojects]

Got it!
This is a chicken and egg situation:

You need to generate the configuration to load the .env file, but you need the content of the .env file to generate the configuration.

TBH I'm not too happy the way templates work right now but sadly it's going to take time to replace it with something more flexible

[2q2code]

I haven't yet tested if the env-file is working properly, but I managed to get the "outer" environment sorted so dynamic profiles are generated in response to an environment variable. I will do more testing as I go on with it.