[Feature Request] Expose more environment variables to hooks

[Chostakovitch]

Hi everyone !

Since #1518, rustic gives hooks a bit of context for backups, but I think it would be nice to have that for other commands. My use case is especially monitoring/alerting.

However I feel that too much variables would result in too much specific code and difficulties to document/use.

So I propose the following, available for all hooks :

• RUSTIC_COMMAND: command which triggered the hook (prune, snapshots, etc)
• RUSTIC_HOOK_COMMAND: command of the current hook (as a string)

Additionally, run-failed hooks could benefit from:

• RUSTIC_FAILED_COMMAND: command which has failed
• RUSTIC_FAILED_COMMAND_RC: return code of the failed command

Example use case : ability for the hook to take action depending on the command, e.g. issuing a warning for certain failures, ignoring others, while giving sufficient context so that alerts are meaningful (e.g. a cat failure is not the same as a prune failure).

Maybe each *_COMMAND could be separated in two variables: verb and args. I feel this is generic enough to serve a lot of use cases.

I know nothing about Rust, but @rdelaage proposed to help if it makes sense.

What do you think ? @aawsome ?

[aawsome]

Hi @Chostakovitch

I fully agree about RUSTIC_COMMAND.

• RUSTIC_HOOK_COMMAND: IMO the command should be able to do this by itself using $0 or equivalent.
• RUSTIC_FAILED_COMMAND: I think this will be identical to RUSTIC_COMMAND, so this is IMO not needed.
• RUSTIC_FAILED_COMMAND_RC: When run-failed is called, there is no RC set so far. This is done in the end of the call. So I don't know what we should set here. But this (maybe using a different name) could be defined for commands like check or prune to give certain information about the failure.

My proposal would be to implement RUSTIC_COMMAND (anyone willing to do this?) and depict use cases for failure information more in detail - being able to tackle those in another issue.

[Chostakovitch]

Hey,

I should have given an example, command was ambiguous.

Take this configuration excerpt:

[[global.hooks.run-failed]]
command = "/bin/bash"
args = ["..."]

[backup.hooks]
run-before = [
    "/path/to/dump.sh",
]

If I launch rustic backup and that dump.sh fails, the backup fails (unlike on_failure is set...). I would like to provide to the run-failed command:

• rustic command (backup);
• failed hook (dump.sh);
• failed hook RC.

You're right for the current hook command, $0 will do.

For the others, even if I often have to deal with failed run-before hooks, the use case is maybe too niche to implement.

---

Maybe a better idea would be, as you suggested, to provide hooks with a RUSTIC_FAILED_REASON-ish variable, which could be command-dependent (so that check or prune and others can make a short summary), or, if it's about a hook as in my example, contain the hook command and RC.

---

Hopefully if we agree on something the original PR author can help.

[Chostakovitch]

Hey @aawsome, what do you think about keeping RUSTIC_COMMAND as you suggested and adding RUSTIC_PROFILE, so hooks can be factorized, and forget about my other suggestions which are too specific.

Also, a bit off-topic but asking before opening another issue, is it expected that global hooks are not triggered by e.g. copy?

[aawsome]

Hey @aawsome, what do you think about keeping RUSTIC_COMMAND as you suggested and adding RUSTIC_PROFILE, so hooks can be factorized, and forget about my other suggestions which are too specific.

profile is a bit ambiguous here: Do you mean the profile rustic is called with or the profile the hook is defined within?

Also, a bit off-topic but asking before opening another issue, is it expected that global hooks are not triggered by e.g. copy?

Are you talking about the hooks of the target repository? If this doesn't work, please open a bug issues!

[Chostakovitch]

Do you mean the profile rustic is called with or the profile the hook is defined within?

@aawsome the profile passed on the CLI, which feels more useful to be (if hooks are defined in a generic, included profile, it could be very useful for hooks to "know" this).

Along with RUSTIC_COMMAND, alerting would be more easy by letting users know which command failed on which profile (configuration file).