Question: State option on command hooks #1073

New issue

Closed

opened 2025-04-15 08:31:49 +00:00 by mrclschstr · 5 comments

mrclschstr commented 2025-04-15 08:31:49 +00:00

Copy link

Hi Dan,

I'm trying to understand the new "states" option on the command hooks that were added in version 2.0.3. Normally I don't have complicated commands and just use commands that I run before and after backups (create step). What exactly would be the difference in the following two hooks?

- after: action
  when: [create]
  states: [fail]
  run:
    - echo "Something went wrong"

- after: error
  run:
    - echo "Something went wrong"

As I understand it, both are executed in case of an error in the create step, or am I wrong? Are there situations where I should rather use one or the other?

Kind regards,
Marcel

Hi Dan, I'm trying to understand the new "states" option on the command hooks that were added in version 2.0.3. Normally I don't have complicated commands and just use commands that I run before and after backups (create step). What exactly would be the difference in the following two hooks? ```json - after: action when: [create] states: [fail] run: - echo "Something went wrong" ``` ```json - after: error run: - echo "Something went wrong" ``` As I understand it, both are executed in case of an error in the create step, or am I wrong? Are there situations where I should rather use one or the other? Kind regards, Marcel

witten commented 2025-04-15 15:45:59 +00:00

Owner

Copy link

You are correct in identifying this as a documentation gap that needs fixing. The basic difference between the two examples you've included is that one runs sooner than the other. The after: action hook runs immediately after the create action fails for a particular repository—so before any subsequent actions for that repository or other repositories even have a chance to run. Whereas the after: error hook doesn't run until all repositories in a configuration file have had a chance to execute.

You are correct in identifying this as a documentation gap that needs fixing. The basic difference between the two examples you've included is that one runs sooner than the other. The `after: action` hook runs immediately after the create action fails for a particular repository—so before any subsequent actions for that repository or other repositories even have a chance to run. Whereas the `after: error` hook doesn't run until all repositories in a configuration file have had a chance to execute.

mrclschstr commented 2025-04-15 16:27:03 +00:00

Author

Copy link

Thank you for the explanation. So if you only have one repository in the configuration file, it doesn't really make much difference which of the two variants you use. Did I understand that correctly?

Thank you for the explanation. So if you only have one repository in the configuration file, it doesn't really make much difference which of the two variants you use. Did I understand that correctly?

witten commented 2025-04-15 17:32:58 +00:00

Owner

Copy link

It doesn't make much difference, but there's still a small difference—if you've got subsequent actions after create for that one repository, after: action with states: [fail] runs before those actions, while after: error runs after them.

It doesn't make much difference, but there's still a small difference—if you've got subsequent actions after `create` for that one repository, `after: action` with `states: [fail]` runs before those actions, while `after: error` runs after them.

👍 1

mrclschstr commented 2025-04-15 18:04:32 +00:00

Author

Copy link

Many thanks for the (as always 😄) quick reply and the clarification. The question has been clarified for me and the issue can be closed.

Many thanks for the (as always 😄) quick reply and the clarification. The question has been clarified for me and the issue can be closed.

witten commented 2025-04-16 02:59:31 +00:00

Owner

Copy link

Thanks! I'll leave it open for now just as a reminder to clarify this in the docs.

Thanks! I'll leave it open for now just as a reminder to clarify this in the docs.

witten referenced this issue from a commit 2025-04-20 23:00:33 +00:00

Clarify the documentation about when an "after: error" command hook runs and how it differs from other hooks (#1073).

witten closed this issue 2025-04-20 23:00:40 +00:00

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

Subscribe

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#1073

No description provided.