| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This makes define and class parameters support optionally typed
parameters when using the future parser. The type expressions
are evaluated by the Pops Bridge when parameters are transformed t 3x.
The 3x parameters are not aware of type information (they are encoded as
arrays), and changes to all the logic that deals with parameters turned
on to not be a good design. The resource type and resource is instead
made aware of the opt-in types via a separate param-name to type map
that it applies in the validation step that was already performed.
|
|
An empty string is no longer undef when parser is future, and will
evaluate as true in a conditional test. This commit fixes a test that
was failing this check for the future parser. This, and several like
it, was an acceptance test which was just compiling a simple manifest
with some conditional logic to test evaluation of conditionals. Since
acceptance tests are expensive, I've pulled them back into the
integration specs.
The actual test being fixed is
acceptance/tests/apply/conditionals/should_evaluate_empty.rb which is
now the two 'evaluates empty string as <false|true>' specs in the new
spec/integration/parser/conditionals_spec.rb
|
|
Previously this spec's tests were a shared_example that had been shared
between runs with parser=current and parser=future. The future compiler
tests were moved out into
spec/integration/parser/future_compiler_spec.rb in 7a6a7d8. This maint
fix just removes the unused rspec construction of shared_examples_for
from around the specs in parser/compiler_spec, since they are only being
run against the current parser now.
|
|
(PUP-121) remove relative name spacing
|
|
The attempt to make all catalogEntryTypes absolute did not
work out so great as the lower level APIs in 3x expect non :: prefixed
names to be absolute.
This changes the transformation made in the evaluator to always use
"relative" names.
|
|
When the 3x to 4x calls take place, resource references in the form
of a PCatalogEntryType are transformed to Puppet::Resource.
Depending on where these (reference) Puppet::Resource instances are
used they need to either be absolute, or not (yes, 3x is inconsistent).
Since future parser in 3.7 (and later 4.0) will not support dynamic
name scoping, the PCatalogEntryType's should in general be absolute.
This commit changes the transformation to make the created
Puppet::Resource (references) absolute (when it is possible).
This also adds more tests
|
|
* upstream/stable:
(maint) Remove failure for empty generated tags
(maint) Update test to use resource matcher
(maint) Add sitemoduledir to env env tests
(PUP-2689) Make AST Resource check tags against "inherited" tags
(maint) Remove unused Puppet::Parser::AST::Tag class
|
|
The other test added for checking the tagging behavior used the resource
matcher but the current compiler spec didn't. This updates it to be
consistent with the future compiler spec and use the matcher.
|
|
This overrides the tagged? method in AST Resource to also search
for tags in its containing resource. These tags will be set when
the resource is finalized (just before serialization on transformation
to external format).
If this is not done, resources will have a different tag set when
a search is made for the node itself (exported or virtual) vs. searching
external resources.
This also correct minor problems with passing an array (which could
result in an array being set as a tag).
It was also possible for empty tags to be set if a string tag contained
multiple :: in sequence, or if ending with ::. Now an error is raised
for these conditions (just like for empty segments generated by using a
sequence of commas (which was on a different code path).
|
|
WHen future parser is in effect, the lookup of default values
will now not look in "parent scopes" (i.e. scopes that *contain*
the resource). Instead it now only looks in inherited and enclosing
scopes + itself.
This removes the confusion that occurs when a class may be included
from different locations, and the location that wins manages to impose
the defaults from its scope.
This removal goes hand in hand with dynamic scoping being removed
everywhere else.
|
|
The new parser has been updated to be able to handle nodes with numeric
names and so the test for that case now passes for both the current and
future parser. The only remaining case is when the name is an invalid
number. The future parser won't ever parse this correctly and so the
test has been changed to assert the desired behavior, in which the
parser fails.
The new changes to the parser also allows it to handle dotted names and
so a new test has been added for that.
|
|
There were no tests that tried to specify how node statements are
selected. This adds coverage for various ways in which a node statements
can match a given node object and varifies that the future evaluator and
the current evaluator produce the same results.
There are 2 cases where the future evaluator isn't able to handle the
same node statements: using numbers. One case, where a name begins with
a number, seems completely reasonable. The other case, where the name is
a valid number, seems like an arbitrary restriction and so we need to
discuss.
|
|
A catalog used to have the symbolic name if it's environment set, but
did not retain a reference to the actual environment instance. This
could would likely allow the catalog to reference it's original
environment for a legacy, memoized environment, but does not work with
newer cacheing models for directory environments. The problem was
showing up specifically in the
spec/integration/parser/ruby_manifest_spec which would compile a catalog
and then interrogate the catalog to see if it contained the expected
resources. Resources have unfortunate behavior causing them to lookup
environment in order to load types in support of the
Resource#parse_title. But the current_environment retrieved by the
resource in the spec was likely different than the one overridden during
compilation, and if it had never performed an initial import, might fail
attempting to lookup classes which were not on its path.
To short circuit some of this madness, the compiler is explicitly
setting a new Catalog#environment_instance, and Catalog#to_catalog is
ensuring that it copies when duplicating. Catalog#resource then
overrides current_environment to this instance.
|
|
Using the have_resource matcher makes the tests a little shorter and
more expressive. It also uses the common way of matching so that we can
get better error reporting.
It turns out that one of the tests was matching against the incorrect
class name, so that is now fixed.
This also extracts a be_resource matcher so that you can match against
an individual resource independent of a catalog.
|
|
The tests used various ways to contruct the catalog. However, putting
together a catalog isn't always as simple as just calling compile.
compile_to_catalog puts all of the steps together in a way that is easy
to use in the tests.
|
|
When defaults were set using future evaluator and the resource has
a qualified name, the registration of the default was not recognized
because scope requires every segment of a qualified name to be upper
cased.
This adds upper casing of every segment. An integration test checks
that the capitalization works.
|
|
The problem was that nil was not transformed to undef for the result
of a parameter default expression and nil was interpreted as value
missing by the 3x class/define logic.
This adds a transformation in the PopsBridge by introducing a new kind
of bridging expression. Likewise, a transformation was needed back again
to nil as the value was set in TypeCalculator when performing an
inference and symbol :undef can not be used where a String is expected.
It was also observed in PUP-1964 that the error that surfaced lacked
location information. This was caused by the transformation of
unparenthesized call, where the transformed call expression did not
get location information set.
Tests added for the two different problems.
The factory method for recording position now also checks if the
end_locateable is void of location information (which can happen
in some transformations).
|
|
The change in PUP-1220 (turning off access to dynamic scope)
accidentally also turned off access to inherited scope.
This is a big problem because it blocks the most used pattern of getting
parameters into classes in modules (and then accessing them in
templates).
|
|
ffrank/ticket/master/22800-dynamic-lookup-in-templates
(PUP-1220) apply proper scoping rules to scope#to_hash
|
|
'adrienthebo-issue/master/pup-542-deep_freeze_arrays_numerics_booleans'
* adrienthebo-issue/master/pup-542-deep_freeze_arrays_numerics_booleans:
(PUP-542) Test the gamut of mutation
(maint) Detect reparse when :code changes
(maint) Allow arrays, bools, and numerics to be frozen
|
|
There are a lot of ways that the facts hash could be mutated. This
checks that none of those ways can happen.
|
|
The last segment of a qualified variable name is allowed to start
with an underscore. Previously this was only allowed for a single
segment.
|
|
|
|
When opting in with trusted_node_data or immutable_node_data the facts
are also available via $facts, an immutable hash of data.
|
|
As suggested by Henrik Lindberg, make the parser only behave correctly
when parser=future is configured. If working manifests rely on the
regression, the next point release won't break them. Instead, users can
test for this using the configuration setting.
The next major release should adopt the fix as standard behavior and
the legacy support should be removed. Since the variable lookups in
templates relies on the accessing of local attributes, there is no
way to issue deprecation warnings to users.
|
|
The fix for #1427 added an instance method to the scope class
for exporting all variables from the local scope. This method
apparently re-implemented the dynamic scoping rules.
When those were removed, the #to_hash method was left as was.
As a result, dynamic scoping still worked from within templates,
when using the @variable syntax in the erb code.
Fix this by using the new #enclosing_scope method so that proper
scoping rules are used instead.
|
|
This changes scope_spec to run for both current and future parser.
(At this point, the future evaluator still has issues; to be
fixed in coming committs).
|
|
The test only checked if it was possible to append to an array
in an outer scope by creating two notify resource based on the
array. This test does not have to run as part of the acceptance tests
and was moved to catalog_spec in integration.
This also makes catalog_spec run for both current and future parser.
(The future parser still has issues at this point; to be fixed in
later commits).
|
|
|
|
Add a test to confirm the effect of the fix for a puppetdoc bug.
|
|
We need to pop from commentstack in the grammar whenever we parse a
hash; an LBRACE pushes to commentstack, yet an AST::ASTHash does not
have a doc string which would get the comment popped from the stack
again. This left an extra item on the commentstack which caused all
subsequent Lexer#getcomment to return "".
Make the test for "comments before statement" contain a more complex
example to demonstrate that nested comments should not be returned.
|
|
The vaidation was changed from a specific relationship validation
to using just R-Value check. This was a mistake since a
CollectExpression is a valid operand in a relationship even if not
producing an R-Value. Old version resurrected and streamlined to do
either R-Value check, or check that operand is a Collector.
|
|
|
|
4 tests were failing because Puppet[:hashed_node_data] was renamed
to Puppet[:trusted_node_data]. This commit changes the failing tests
to use the renamed setting.
|
|
(This was missing in an earlier commit)
|
|
|
|
There were several problems with the query (Collector) implementation.
The CollExpr matching logic used Ruby == and Ruby include? instead
of Puppet Operators. This meant that numeric values in string vs.
numeric form were not comparable. This is now changed by using an
alternative implementation of CollExpr evaluate when Puppet[:parser] ==
future.
The relationship operator implementation did not support handling a
Collector (the result of evaluating a CollectExpression). The 3x
compiler is responsible for late evaluation of the Collector, and a
relationship formed with a Collector was not implemented. Now the
Collector is passed verbatim as operand in a Relationship, and passed on
to the compiler.
|
|
Tests from the parser integration tests were added to the unit tests
for the new evaluator (they were not very good integration tests). The
old test ran for both "current" and "future" and now only run for
"current". The relevant tests were moved to the evaluator unit tests.
This showed several problems in the PopsBridge (typos) for yet
unexercised code paths. These are now fixed.
As the integration/parser/compiler_spec tests were being investigated
to run also for the new parser, problems were found with comparison
against literal undef. Tests were added for this in the evaluator unit
test and the problem corrected (undef compared as :undef == nil => false
which is not the intention. Comparsions :undef == nil, and nil == :undef
are now done correctly.
Exceptions did not show up correctly when file is empty string. This
also fixes the logic where it is checked if a file is known (nil and
empty string are now considered to be "file unknown" instead of file ""
known.
|
|
This adds the setting :strict_variables. When used the scope
will throw :unkown_variable (which if not handled, will raise
an exception). The future evaluator can handle this, but none of
the other parsers/evaluator options. Testing of the future evaluator
turns on strict variables mode (and has tests that an error is raised).
This commit also contains maintenance (removal of unused code), fixing
of the pops bridge (special case when evaluating without a proper boot)
|
|
In Ruby 1.8.7, the error message for an attempt of mutating
a frozen hash refers to 'hash' using lower case whereas later versions
use capital 'H'. This caused two tests to fail (twice).
|
|
This renames hashed_node_data to trusted_node_data, and
the element 'clientcert' to 'certname'.
This also fixes the issues regarding immutability reported in PP-773.
It is now not possible to alter the trusted data. (A freeze was missing
when the data was created). As extra precaution, the data is frozen when
set as trusted data in the node.
There is now also a warning if an attempt is made to modify the trusted
data by manipulating a node.
|
|
This adds a new feature where it is possible to opt in to getting a top
scope variable $trusted to contain a hash of trusted data.
The setting that controls this is called hashed_node_data (it is
intended to later also be used for hashed facts as well as the hashed
trusted data; hence its more generic name).
The variable $trusted is only available if :hashed_node_data is set to
true (the default in 3.x is false).
The hash contains the key 'authenticated' which is always set to one of
'remote', 'local' or boolean false. The key 'clientcert' is set if
'authenticated' is set to 'remote' or 'local'.
|
|
The test was wrong (inadvertent inclusion of an unexpected error while
testing ability to catch a different problem).
|
|
The functions test for thread safety, after many runs after having
removed the thread safety code, still did not fail. This removes the
test.
|
|
The catalog integration spec was originally intended as just to be about
the order in which some elements appeared in it, but it has evolved to
be about the general invariants and properties of the catalog as it is
transmitted between the master and the agent.
|
|
This adds assertions that the virtual resources are not sent to the
agent, and neither are exported resources.
|
|
The order that resources are added into the catalog is needed in order
to ensure a less surprising order when applying resources on the agent.
This ensures that the order that resources are transmitted to the agent
preserves that insertion order.
|
|
This adds a specification to the order in which resources appear in the
catalog. They must appear in the order in which they are added to the
catalog.
In order to make this kind of assertion easier this commit also brings
in Ramcrest.
|
|
This adds checks for validation of non rvalue producing expressions
that can be created with the current concrete syntax. (Combinations
that can not be created via the current egrammar are not included since
it is difficult to create them).
|
|
The validation of hostname expressions did not produce good messages
for interpolated string (syntax error vs. detailed error). Relaxes the
grammar to accept a concatenated string which is then validated.
Refactors parameter name from 'node' to 'semantic' in hostname_xxx
checks (the role of the parameter is to provide semantic location, it is
not required to be a node).
Contains additional tests for other (already passing) detailed errors.
|
