Description
Due to the way scheduled-script.sh pulls in its config from the config file, the contents of
that file will override any env vars you specify on the command line below.
That fix is in itself needed to work around the empty environment that cron gives you.
Bad effects of this are as described in deployment.md, you need to edit the config file (and remember to put it back!) before running an ad-hoc re-processing task.
It also makes the integration test harder to implement than it needs to be.
Definition of Done
Comments
Suggested fix is to add an option to scheduled-script.sh, such as --read-config-from-file, to tell it to read the envs from the bind-mounted config file, as it does currently. This option will be specified in the crontab to keep that current behaviour.
When run from an ad-hoc script such as docker compose run --entrypoint /app/exporter-scripts/scheduled-script.sh waveform-exporter you don't specify that option, so env vars will just be inherited as normal (cron is bypassed in this case so the fix is not needed).
Description
That fix is in itself needed to work around the empty environment that cron gives you.
Bad effects of this are as described in deployment.md, you need to edit the config file (and remember to put it back!) before running an ad-hoc re-processing task.
It also makes the integration test harder to implement than it needs to be.
Definition of Done
Comments
Suggested fix is to add an option to scheduled-script.sh, such as --read-config-from-file, to tell it to read the envs from the bind-mounted config file, as it does currently. This option will be specified in the crontab to keep that current behaviour.
When run from an ad-hoc script such as
docker compose run --entrypoint /app/exporter-scripts/scheduled-script.sh waveform-exporteryou don't specify that option, so env vars will just be inherited as normal (cron is bypassed in this case so the fix is not needed).