Closed mdschmitt closed 2 years ago
@myii , how's this look?
No major rush, but any word on this?
@myii , dropping another bump in here. Any feedback on my revisions?
Latest CI failure because ArchLinux properly uses systemd timers rather than cron. Requires deeper code tweakage to properly provide for. This PR on hold until I can get that to be better.
@mdschmitt Thanks for the additions. I've tested some changes in my own fork to ensure Arch Linux is working as well. I'll push those here and merge this PR shortly.
One question remains: which reference did you use for the /etc/logrotate.hourly.d/...
path? I couldn't find any mention of it in the upstream repo:
:tada: This PR is included in version 0.13.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
Wow @myii , thank you so much for doing this. You beat me to writing the kitchen test and I definitely would have ended up rewriting things to allow for Arch. Folding in cron-formula
as a dependency is much cleaner though.
As far as the naming for "logrotate.hourly.d", it was just a logical canonicalization of "logrotate.d" with the explicit addition of "hourly" since hourly isn't out-of-the-box functionality. Inspiration taken from https://sleeplessbeastie.eu/2018/07/11/how-to-execute-logrotate-every-hour
No problem -- thanks for the reference, @mdschmitt.
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]
Changes related to the build system[chore]
Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]
Changes to the continuous integration configuration[feat]
A new feature[fix]
A bug fix[perf]
A code change that improves performance[refactor]
A code change that neither fixes a bug nor adds a feature[revert]
A change used to revert a previous commit[style]
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]
Documentation changes[test]
Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE
?Not unless existing pillar values for clients have "hourly" set in their job configurations. ...in which case, they already don't work straight-out-of-the-box.
Related issues and/or pull requests
Describe the changes you're proposing
Pillar / config required to test the proposed changes
Debug log showing how the proposed changes work
Documentation checklist
README
(e.g.Available states
).pillar.example
.Testing checklist
state_top
).Additional context