Use env variable in send-before url
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?
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 🙇🏻
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.
https://github.com/creativeprojects/resticprofile/blob/63dee21a1beaa3d72df3666365363b43b40c26a4/monitor/hook/sender.go#L230
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.