summaryrefslogtreecommitdiff
path: root/spec/unit/provider/cron/parsed_spec.rb
AgeCommit message (Collapse)AuthorFilesLines
2014-03-26Merge pull request #2331 from ticket/master/PUP-1587-catch-empty-cron-entriesCharlie Sharpsteen1-0/+15
(PUP-1587) crontab: make sure that invalid crontabs aren't written out (PUP-1586) remove obsolete unit test (PUP-1586) allow managing existing cronjobs without caring for command Signed-off-by: Charlie Sharpsteen <Charlie Sharpsteen chuck@puppetlabs.com>
2014-02-11(PUP-649) Loosen checks for crontab providerAndrew Parker1-31/+27
The tests for the crontab provider exhibited an order dependent failure. If the spec/integration/provider/cron tests were run before the spec/unit/provider/cron tests then the global counter that is used by the crontab provider would not be at the expected value. This isn't really a problem in practice, but the expectations in the tests were for a specific count. This updates the checks so that they are resilient to the exact numbers chosen.
2014-02-11(#3220) uniquify implicit record namesFelix Frank1-2/+2
Adds an numeric suffix to the artifical name that gets generated for unnamed records in crontabs. It will suppress naming collisions for cronjobs that use the exact same command string.
2014-02-11(#3220) make the unit test "generating cron resources" match the new behaviourFelix Frank1-2/+2
To allow purging of unmanaged resources, they are now implicitly named. The unit test must take that into account.
2014-02-05(PUP-1586) allow managing existing cronjobs without caring for commandFelix Frank1-0/+15
When the catalog contains a cron resource that does not specify a value for the command property, the transaction would fail with the cryptic error message 'no command, somehow' under certain conditions. This error is spurious. Generally, it's quite allowable to manage a subset of cron properties that does not include the command. Fixed by removing the devfail invocation. The command property is now handled just like the 'special' property.
2013-03-22(maint) Refactor crontab filetype selectionAdrien Thebo1-5/+11
The previous implementation of the crontab implementation type determined the filetype to use at load time by calling out to Facter before the type was loaded, which was both ugly and made it difficult to test on alternate platforms. This commit overrides the `.filetype` method to do the detection at runtime so the provider encapsulates all its logic and the filetype can be stubbed out.
2013-03-13(#16809) Use only one record_type in cron providerStefan Schulte1-0/+319
The cronprovider defines two record_types :crontab and :freebsd_special to handle the following crontab records: @daily /bin/my_daily_command 0 0 * * * /bin/my_daily_command This has a few issues: a) The merging of the name (the comment before the cronentry itself) and the environment variables only happens for the :crontab record_type but not for the :freebsd_special record_type so information may get lost (#16809) b) When parsing an existing record the record_type can be automatically determined (depending on which regex matched) but when creating a new entry the record_type is undefined and the default :crontab is used. So if a new cronentry is created with the :special property set it is still treated as a crontab entry (so the to_line hook of the :crontab record_type is used and not of the :freebsd_special record_type) which is kind of confusing. c) It is really hard to change the time of a cronentry from the special format to a normal format (or vise versa) e.g. if we already have the following cronentry # Puppet Name: foo * * * * * /bin/foo and we have defined the following resource cron { "foo": special => daily, } the resource is treatd as in sync because the existing cronentry is parsed as a :crontab record_type and this record_type doesn't define a :special field that could be out of sync This patch now only uses one record_type that internally parses the timefield as either the old format (minute,hour,monthday,month,weekday) or the special format. This way the above issues go away (but the different to_line, post_parse hooks get a bit more difficult to handle both entries)