Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'tag' works beautifully when applied to the root of profile but produces warning #256

Open
arberg opened this issue Sep 17, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@arberg
Copy link

arberg commented Sep 17, 2023

If using root-level tag I get one of these two warnings depending on whether its applied as list or single key-value

yaml:
  onedriveMinecraft:
    inherit: onedriveMain
    tag: "minecraft"
Output:
key/value: Failed parsing profile section "tag": '' expected a map, got 'string'

yaml:
  onedriveMinecraft:
    inherit: onedriveMain
    tag:
      - "minecraft"
Output:
list: Failed parsing profile section "tag": '' expected a map, got 'slice'

Note that restic is correctly invoked with the tag, even when applied to the root profile. This goes for both backup (+auto forget with retention: after backup), snapshot and forget (those are what I have tested)

>resticprofile onedriveMinecraft.backup
2023/09/17 09:44:39 starting command: /usr/bin/restic backup --host=tower --password-file=restic-encryption-password.txt --repo=rclone:OneDriveAll:backup/restic/media --tag=minecraft --verbose=1 /mnt/cache/dockerhub/minecraft
...

> resticprofile onedriveMinecraft.snapshots
ID        Time                 Host        Tags                  Paths
-----------------------------------------------------------------------------------------------
e44a51da  2023-09-17 09:43:03  tower       minecraft,minecraft2  /mnt/cache/dockerhub/minecraft
---------------------------------------

I know I can apply the tag to backup, but if I do that, then tag isn't applied to snapshot, and I have to duplicate it. I guess it can make sense to have a tag only on backup and not on snapshots, if using multiple tags but for me it seems I just want one tag to identify the backup. If I apply an outer and an inner tag, the outer tag is lost, but that seems to be the standard way for inheritance as well, so that makes sense (well except for backup.verbose: 0, which is ignored instead of overwritten root, but I'm sure that's another thing).

Is this intended?

I notice the docs do not mention tag in the root of profile. Is that something I should avoid because it might break in the future, as its 'unsupported'?

I'm using yaml version 2, and

resticprofile 0.23.0 compiled with go1.20.7
2023/09/17 09:53:24 using configuration file: profiles.yaml
2023/09/17 09:53:24 loading: profiles.yaml
2023/09/17 09:53:24 memory available: 12262MB
2023/09/17 09:53:24 restic 0.16.0
@creativeprojects
Copy link
Owner

Hi,

The reason it's not a tag expected on the profile configuration is because it's not a flag for some commands. All the flags at the root would be applied to any command.

I suppose we could support it, and it would only be applied to the commands that accept the flag.

I can't guarantee we will support it though: it depends on how more complex it's going to make the compilation into flags. It's already getting quite complicated 😉

I guess you can still use it, but be aware that it might break in the future. Also we have no test covering this case 👍🏻

@creativeprojects creativeprojects added the enhancement New feature or request label Sep 17, 2023
@jkellerer
Copy link
Collaborator

jkellerer commented Sep 18, 2023

Based on what we documented "Most supported flags can be set in this way at profile level" (https://creativeprojects.github.io/resticprofile/configuration/inheritance/index.html#common-flags) .. I think we should support it for all common flags (including tag).

In-deed a test (and a fix for the warnings) is missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants