Use env variable in send-before url

[RazielleS]

I am trying to set up sort of a template default configuration which I can distribute between all of my machines.
My main issue right now is to get the healthcheck url right. I want this to be configurable without changing the yaml.
But I can't get the URL using the HEALTHCHECK_KEY from the env file.
The variable of course is set in the env file, and I have other variables needed for the Backup repository configuration in there, so I know it is loaded.

Right now the relevant config looks something like this:

default:
  env-file: ./profiles.env
  backup:
    send-before:
      body-template: send-body-template.json
      method: POST
      url: https://healthcheck.example.org/ping/$HEALTHCHECK_KEY/${PROFILE_NAME}/start?create=1

However, when I dry-run the command, the variable seems to be empty, I get this output:

dry-run: webhook request method=POST url="https://healthcheck.example.org/ping//default/start?create=1" headers:

Is it not possible to use an env variable from env-file at this position right now?
Same thing happens in the send-after and send-after-fail sections.

Interesting part is, if I call resticprofile like HEALTHCHECK_KEY=test resticprofile --dry-run backup the variable is used as it should.
The same thing happens when I try {{ .Env.HEALTHCHECK_KEY }} instead.
But I think this would not work with the schedules and I would need to source the env file before running the command manually.

Any idea what is happening here?

[creativeprojects]

Hey!

Sorry for the late reply.

This is definitely a bug:

• the environment variables are resolved on all the run-* targets
• the environment variables are not resolved on the send-* targets

I'll have a look at it soon-ish 🙇🏻

[zumm]

Problem is Sender uses os env instead of profile env, so any env vars set in profile env or env-file sections are empty in URL and body.

resticprofile/monitor/hook/sender.go

Line 230 in 63dee21

return os.Getenv(s)

So we need to pass the profile env to Sender itself or Send method (I think the latter is preferable). I might address this in a new pr after merging #538.