-
Notifications
You must be signed in to change notification settings - Fork 14
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
validate_cron can't deal with crontab whose commands may vary #112
Comments
hello again @stevemil00! from your report, i understand that the one of the problems/concerns in play here is that we want to support cron entries whether they were created by Puppet or not, so we can't rely on the i was thinking that the last command that you specified ( taking a step back - what would be useful?
then you could oh, and either way, i think we should standardize on 'crontab', so will rename |
I'm a little unclear what changes need to be made, too. :) Like you said, if you change the code to search the array, I think we might end up with an unpleasant side-effect in which we could get matches that wouldn't match now (so we might break existing tests). That might depend on how If the only thing that uses
You'd only put things with puppet names in the And You could just stuff the puppet name in alongside That's not perfect but it might work. The only other thing I could think of would be to force the user to indicate somehow that something should be a regex match (maybe by passing the slashes in, like Did that help at all? |
Hi. Let's say you have something like this in a puppet manifest:
there's no way to check that using
validate_cron()
.The cron entries are loaded using
get_crontab()
, which generates a hash that looks like:So when you call
validate_cron()
, you're passing in a user and a command, but unless you can vary the command in the test to match the hostname for everything you're testing, you're kind of stuck.Sometimes you can vary that in the test, but if you're trying to read a bunch of canned files and cron entries and services and the like in to test, there's probably not a great way to deal with that.
A more practical (well, less pointless) example might be if you needed to fetch some secret dynamically, then stuff that into the cron entry.
If you could validate cronjobs by the puppet name for the cronjob, and/or validate cronjobs by passing in a pattern, that'd help a lot in these cases. For example, the puppet snippet above would stuff something like this in
root
's crontab:so if you could call
validate_cron('root', 'pointlessly-store-my-hostname', expectation)
that'd be useful (and then I guess we could rely on the unit tests to check that the cron entry they store is actually right).Though of course being able to do something like
validate_cron('root', 'echo.*/var/tmp/myhostname', expectation)
wouldn't be terrible, either.The text was updated successfully, but these errors were encountered: