| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(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>
|
|
Just a simple addition to the mock object used for some tests, because
the crontab provider will now perform an additional property value lookup
to find an on-disk resource.
|
|
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.
|
|
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.
|
|
To allow purging of unmanaged resources, they are now implicitly named.
The unit test must take that into account.
|
|
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.
|
|
Using an object of class Puppet::Type::Cron is too error prone, as
instantiation of those objects have a lot of side effects. This replaces
the actual object with a stub to minimize the possible side effects.
|
|
The previous implementation of this spec was exhibiting failures on
windows and was testing behavior out of the scope of the unit test. This
narrows the scope of the given test.
|
|
|
|
This renames the ParsedFile `self.find_resource` method to
`self.resource_for_record` and changes the method return to return the
resource found. It also adds some yardoc for the methods involved.
|
|
This reverts commit c992fb536d9fd87ad23b2fc0b88592bfe1dea0f5.
|
|
This is causing spec failures on windows, and the current implementation
of the crontab provider and the parsedfile provider is sufficiently
complex that it's not clear how to sanely fix this issue. This is
getting reverted until it's in a more understandable state.
This reverts commit f85ec37456095c06a7b0d99a752534d0caf9c97e, reversing
changes made to 138fc337c36715a7ab40b2b68b86aa71ec3ada64.
|
|
The crontab provider will duplicate resources ad nauseam if another
record with the same "puppet name" exists in a different crontab.
It was found that entries in different crontabs, even when sharing
names, should be treated as independent entities. Therefor, the
crontab provider will now ensure that when prefetching crontabs
from disk, cronjobs are matched to managed resources only if both
the name and the target file match.
|
|
The logic for matching new resources with exiting unmanaged cronjobs
has been reworked during the fix for #16809. Somehow, this lead to
a new issue which caused spurious matches, e.g.:
10 * * * * /bin/true
and
cron { "blank": command => "/bin/true", ensure => present }
would now match. At least puppet will not try to change the name of the
record (i.e., the 'Puppet Name:' line). But the new entry will not get
added either. It still works if there is a non-matching time field, e.g.
cron { "blank": command => "/bin/true", hour => 1 }
but without such fields, the behaviour is wrong.
The match method (in the crontab provider) will expressly ignore named
records on disk. This is safe to do; if the resource does have the
same name as the on-disk record, the match method will not even get invoked.
There is no scenario in which we'd want differently named records to be
matched with a resource. If an on-disk record has a name, it either is
managed through another resource, or it used to be managed. Either way,
the resource in question needs adding or matching to a different record.
|
|
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.
|
|
The legacy test::unit crontab tests contained checks for the
freebsd_special record line. Since those were not getting run by the
normal rspec coverage it got missed when the freebsd_special line type
was removed. This commit removes the outdated references.
|
|
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)
|
|
This makes use of the "native header" of parsed files.
Vixie cron headers should never be written back to disk, because
cron will insert a new header, regardless of what's found in the
temporary input file.
The underlying issue is a cron bug, because vixie headers should
(probably) not appear in `crontab -l` output. This is indeed fixed
in newer versions of cron, so this workaround merely introduces
compatibility with older systems.
|
|
Without this patch Ruby 1.9 is still complaining loudly about trying to
parse the spec files. The previous attempt to clean up this problem in
edc3ddf works for Ruby 1.8 but not 1.9.
I'd prefer to remove the shebang lines entirely, but doing so will cause
encoding errors in Ruby 1.9. This patch strives for a happy middle
ground of convincing Ruby it is actually working with Ruby while not
confusing it to think it should exec() to rspec.
This patch is the result of the following command run against the source
tree:
find spec -type f -print0 | \
xargs -0 perl -pl -i -e 's,^\#\!\s?/(.*)rspec,\#! /usr/bin/env ruby,'
|
|
Without this patch some spec files are using `ruby -S rspec` and others
are using `rspec`.
We should standardize on a single form of the interpreter used for spec
files.
`ruby -S rspec` is the best choice because it correctly informs editors
such as Vim with Syntastic that the file is a Ruby file rather than an
Rspec file.
|
|
These tests covered a bunch of content that wasn't already covered, so they
should be ported. Includes some fun around enumerators and Ruby 1.8.5.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
when changed"
This reverts commit c99f394bf8c10d13f3fa7d3ab7ab43ecf454c081.
The fix broke cron jobs in 0.25.3 and was reverted for the 0.25.4 release.
|
|
Merged the "freebsd_special" pattern into the other crontab records,
since its definition was incomplete
Signed-off-by: Jesse Wolfe <jes5199@gmail.com>
|
