borgmatic-collective/borgmatic
borgmatic-collective/borgmatic
Watch
9
74
Fork
You've already forked borgmatic
 57
Code Issues 71 Pull requests 3 Releases 162 Packages 1 Activity Actions 1

borgmatic configuration syntax for more granular exit codes (borg_exit_codes / exit_code / treat_as) on website does not match application syntax #1094

New issue
Closed
opened 2025-05-12 19:11:24 +00:00 by sgiebels · 4 comments
sgiebels commented 2025-05-12 19:11:24 +00:00
Copy link

What I'm trying to do and why

I'm trying to ensure that if borg encounters an error, borgmatic will not ignore/hide it.
This in reference to another ticket I have created,
No error when one my source_directories is not mounted; default value of option 'source_directories_must_exist'

To archieve this, I am following the instructions on:
borgmatic - How to customize warnings and errors - More granular configuration

Steps to reproduce

I've added the following configuration to my borgmatic configuration file:

borg_exit_codes:
    - exit_code: 1
      treat_as: error
    - exit_code: 100
      treat_as: error
    - exit_code: 101
      treat_as: error
    - exit_code: 102
      treat_as: error
    - exit_code: 103
      treat_as: error
    - exit_code: 104
      treat_as: error
    - exit_code: 105
      treat_as: error
    - exit_code: 106
      treat_as: error
    - exit_code: 107
      treat_as: error

and run borgmatic:

# borgmatic --config borgmatic_backup_mnt_mountpoint_directory.yaml create --verbosity 2 --list --stats --log-json

Actual behavior

I get the following error:

borgmatic_backup_mnt_mountpoint_directory.yaml: No valid configuration files found

summary:
/mnt/data/borgmatic.d/borgmatic_backup_mnt_mountpoint_directory.yaml: Error parsing configuration file
An error occurred while parsing a configuration file at /mnt/data/borgmatic.d/borgmatic_backup_mnt_mountpoint_directory.yaml:
At 'borg_exit_codes[0]': Additional properties are not allowed ('exit_code' was unexpected)
At 'borg_exit_codes[0]': 'code' is a required property

Expected behavior

I had expected this parameter to be correct.

Other notes / implementation ideas

I've tried replacing the key 'exit_code' with 'code', and this seems to work (i.e. the configuration syntax is accepted), which makes me believe that there is a mismatch between the code and the documentation describing the syntax.

borgmatic version

2.0.5

borgmatic installation method

pipx

Borg version

borg 1.4.1

Python version

Python 3.11.2

Database version (if applicable)

No response

Operating system and version

Debian GNU/Linux 12 (bookworm)

### What I'm trying to do and why I'm trying to ensure that if borg encounters an error, borgmatic will not ignore/hide it. This in reference to another ticket I have created, [No error when one my source_directories is not mounted; default value of option 'source_directories_must_exist' ](https://projects.torsion.org/borgmatic-collective/borgmatic/issues/1092) To archieve this, I am following the instructions on: [borgmatic - How to customize warnings and errors - More granular configuration](https://torsion.org/borgmatic/docs/how-to/customize-warnings-and-errors/#more-granular-configuration) ### Steps to reproduce I've added the following configuration to my borgmatic configuration file: ``` borg_exit_codes: - exit_code: 1 treat_as: error - exit_code: 100 treat_as: error - exit_code: 101 treat_as: error - exit_code: 102 treat_as: error - exit_code: 103 treat_as: error - exit_code: 104 treat_as: error - exit_code: 105 treat_as: error - exit_code: 106 treat_as: error - exit_code: 107 treat_as: error ``` and run borgmatic: ``` # borgmatic --config borgmatic_backup_mnt_mountpoint_directory.yaml create --verbosity 2 --list --stats --log-json ``` ### Actual behavior I get the following error: ``` borgmatic_backup_mnt_mountpoint_directory.yaml: No valid configuration files found summary: /mnt/data/borgmatic.d/borgmatic_backup_mnt_mountpoint_directory.yaml: Error parsing configuration file An error occurred while parsing a configuration file at /mnt/data/borgmatic.d/borgmatic_backup_mnt_mountpoint_directory.yaml: At 'borg_exit_codes[0]': Additional properties are not allowed ('exit_code' was unexpected) At 'borg_exit_codes[0]': 'code' is a required property ``` ### Expected behavior I had expected this parameter to be correct. ### Other notes / implementation ideas I've tried replacing the key 'exit_code' with 'code', and this seems to work (i.e. the configuration syntax is accepted), which makes me believe that there is a mismatch between the code and the documentation describing the syntax. ### borgmatic version 2.0.5 ### borgmatic installation method pipx ### Borg version borg 1.4.1 ### Python version Python 3.11.2 ### Database version (if applicable) _No response_ ### Operating system and version Debian GNU/Linux 12 (bookworm)
witten commented 2025-05-12 19:16:01 +00:00
Owner
Copy link

Welp, looks like the docs are just plain wrong! Change exit_code: to code: and it should work for you. I'll update the docs.

Welp, looks like the docs are just plain wrong! Change `exit_code:` to `code:` and it should work for you. I'll update the docs.
witten commented 2025-05-12 19:18:15 +00:00
Owner
Copy link

Fixed in main! The updated docs should be live shortly. Thank you!

Fixed in main! The updated docs should be live shortly. Thank you!
sgiebels commented 2025-05-12 20:11:47 +00:00
Author
Copy link

  1. Another small remark: The tab-size / indent on that website is 3 spaces, where on the other pages it is '4'

  2. I believe the following text on that same page is not correct anymore since Borg 1.4:

For instance, to elevate Borg warnings to errors, thereby causing borgmatic to error on them, use the following borgmatic configuration: ..

borg_exit_codes:
   - code: 1
     treat_as: error

Borg (>=1.4) returns extra warning exit codes (in the range 100..107) in addition to 'code: 1'. These warning exit codes won't match 'code==1', and thus won't make borgmatic elevate all warnings into an error.

I don't see any other way to elevate all warnings (code 1,100..107) into an error, other than to specify each of them:

borg_exit_codes:
    - code: 1
      treat_as: error
    - code: 100
      treat_as: error
    - code: 101
      treat_as: error
    - code: 102
      treat_as: error
    - code: 103
      treat_as: error
    - code: 104
      treat_as: error
    - code: 105
      treat_as: error
    - code: 106
      treat_as: error
    - code: 107
      treat_as: error
1. Another small remark: The tab-size / indent on that website is 3 spaces, where on the other pages it is '4' 2. I believe the following text on that same page is not correct anymore since Borg 1.4: > For instance, to elevate Borg warnings to errors, thereby causing borgmatic to error on them, use the following borgmatic configuration: .. > ``` > borg_exit_codes: > - code: 1 > treat_as: error > ``` Borg (>=1.4) returns extra warning exit codes (in the range 100..107) in addition to 'code: 1'. These warning exit codes won't match 'code==1', and thus won't make borgmatic elevate all warnings into an error. I don't see any other way to elevate all warnings (code 1,100..107) into an error, other than to specify each of them: ``` borg_exit_codes: - code: 1 treat_as: error - code: 100 treat_as: error - code: 101 treat_as: error - code: 102 treat_as: error - code: 103 treat_as: error - code: 104 treat_as: error - code: 105 treat_as: error - code: 106 treat_as: error - code: 107 treat_as: error ```
sgiebels reopened this issue 2025-05-12 20:11:47 +00:00
witten commented 2025-05-12 21:20:31 +00:00
Owner
Copy link

Another small remark: The tab-size / indent on that website is 3 spaces, where on the other pages it is '4'

Fixed, thank you!

I believe the following text on that same page is not correct anymore since Borg 1.4:

Good catch! I'll clarify that that approach is only for Borg < 1.4.

I don't see any other way to elevate all warnings into an error, except than to duplicate the syntax below for every value of N in range 100..107:

That's correct.

> Another small remark: The tab-size / indent on that website is 3 spaces, where on the other pages it is '4' Fixed, thank you! > I believe the following text on that same page is not correct anymore since Borg 1.4: Good catch! I'll clarify that that approach is only for Borg < 1.4. > I don't see any other way to elevate all warnings into an error, except than to duplicate the syntax below for every value of N in range 100..107: That's correct.
🎉 1
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
parallel-borgmatic
command-hook-steps
2.1.7
2.1.6
2.1.5
2.1.4
2.1.3
2.1.2
2.1.1
2.1.0
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.1
2.0.0
1.9.14
1.9.13
1.9.12
1.9.11
1.9.10
1.9.9
1.9.8
1.9.7
1.9.6
1.9.5
1.9.4
1.9.3
1.9.2
1.9.1
1.9.0
1.8.14
1.8.13
1.8.12
1.8.11
1.8.10
1.8.9
1.8.8
1.8.7
1.8.6
1.8.5
1.8.4
1.8.3
1.8.2
1.8.1
1.8.0
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.24
1.5.23
1.5.22
1.5.21
1.5.20
1.5.19
1.5.18
1.5.17
1.5.16
1.5.15
1.5.14
1.5.13
1.5.12
1.5.11
1.5.10
1.5.9
1.5.8
1.5.7
1.5.7.dev0
1.5.6
1.5.5
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.22
1.4.21
1.4.20
1.4.19
1.4.18
1.4.17
1.4.16
1.4.15
1.4.14
1.4.13
1.4.12
1.4.11
1.4.10
1.4.9
1.4.8
1.4.7
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.26
1.3.25
1.3.24
1.3.23
1.3.22
1.3.21
1.3.20
1.3.19
1.3.18
1.3.17
1.3.16
1.3.15
1.3.14
1.3.13
1.3.12
1.3.11
1.3.10
1.3.9
1.3.8
1.3.7
1.3.6
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.18
1.2.17
1.2.16
1.2.15
1.2.14
1.2.13
1.2.12
1.2.11
1.2.10
1.2.9
1.2.8
1.2.7
1.2.6
1.2.5
1.2.4
1.2.3
1.2.2
1.2.1
1.2.0
1.1.15
1.1.14
1.1.13
1.1.12
1.1.11
1.1.10
1.1.9
1.1.7
1.1.6
1.1.5
1.1.4
1.1.3
1.1.2
1.1.1
1.1.0
1.0.3
1.0.2
1.0.1
1.0.0
0.1.8
0.1.7
0.1.6
0.1.5
0.1.4
0.1.3
0.1.2
0.1.1
0.1.0
0.0.7
0.0.6
0.0.5
0.0.4
0.0.3
0.0.2
Labels
Clear labels   
blocked

   
breaking

   
bug

   
data loss

   
design finalized

   
good first issue

   
new feature area

   
question / support

   
security

   
waiting for response
No labels
blocked
breaking
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
borgmatic-collective/borgmatic#1094
No description provided.