A number of tools including `lnav` do a crude string matching against
the word "error". For zrepl this results in benign lines being colored
red. It would be better if the logged message was something like
"command ran successfully".
refs
- #872
---------
Co-authored-by: Christian Schwarz <me@cschwarz.com>
Before this PR, config parsing would accept duplicate job names. `zrepl
daemon` would later fail to start with a panic. But tools like `zrepl
configcheck` would pass.
This PR adds a check to ensure job names are unique.
Similarly, internal job names were not being rejected by config parsing
Move that check to parse-time as well.
Last, drive-by change: remove `internal/config/config_include_test.go`
introduced in #856 . These aren't necessary because there is already a
wildcard test for all valid configs.
This PR adds the complimentary "invalid config" wildcard test.
This PR allows for the distribution of zrepl job definitions across
multiple YAML files that are included from the main config.
```
global: ...
include:
- ./zrepl.yml.d
- /opt/zrepl.yml
- ...
```
Refer to the docs changes for details.
Co-authored-by: Christian Schwarz <me@cschwarz.com>
While investigating https://github.com/zrepl/zrepl/issues/700
I checked in on `zrepl status` dependencies and found that
`cview`, which was/is a fork of tview, appears to be unmaintained.
We switched to it 4.5 years ago in a58ce74.
Checking now, `github.com/rivo/tview` seems to be somewhat maintained
again.
I also checked what k9s uses because that tool came to mind as a Go
terminal UI app.
It does use `tview`, but, a fork that has diverged substantially.
Maybe in another 4.5 years stuff the ecosystem has consolidated...
refs https://github.com/zrepl/zrepl/issues/700
Christian Schwarz