| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There were a few formatting problems with the dump action. This fixes
those up and adds tests around the dump functionality.
|
|
The certificate_request, certificate_revocation_list, key, report,
resource, and resource_type faces were added years ago and the tests have
always been pending. Since we've been ignoring those pending tests up to
this point the warnings are clearly not adding value; let's just get rid
of them.
|
|
|
|
Prior to this change, the specs relied on a fragile chain of stubbed
expectations, which changes elsewhere in the application have rendered
incorrect and non-operational.
This change aims to improve these specs by stubbing less and making
more robust assertions about the data.
|
|
Maint/master/update rspec
|
|
|
|
Prior to this commit, when building a module without a Modulefile or metadata.json,
the builder would blow up with a cryptic 'Unable to find module root at DIRECTORY'
It's not entirely clear what that means to an end user.
This commit clarifies that metadata.json or a Modulefile are what need to be found
at the module root. Also removes some duplicated logic for checking module root.
|
|
The goal here was to only produce a fallback environment for the default
'production' environment which would only be found if the production
directory environment did not exist. All other cases would raise an
error during application start up if the environment did not exist.
Except for applications in agent mode which currently need the concept of
the environment they will be requesting, but should not have to create
or verify the existence of a locally matching environment in their
environmentpath.
A few other changes are made to further narrow the scope of code making
open requests for the configured environment:
* indirection request - looks up current environment now, relying on
this having been set by whatever application is making the request.
* puppet apply - instead of creating a new loader with a single static
environment, it overrides current_environment instead.
* puppet util commandline - does not attempt to look for additional
plugins if there is no environment to search in. It relies on
application to raise an error instead, if necessary.
|
|
Module now uses current environment instead of configured
environment when being asked for a module and not supplying
an explicit environment name. It used to lookup to configured
environment giving invoking logic no chance to modify the
default without modifying the setting.
|
|
We define FS as an alias for Puppet::FileSystem in three separate
specs. Unfortunately, describe blocks do not provide any namespacing in
rspec, and this were colliding, issuing two separate warnings for a
redefined constant. Wrapping each spec in its own module provides
separation and elliminates the warnings.
|
|
pvande/feature/master/pup2093_migrate_pmt_to_v3_api
Migrate PMT to the /v3 API.
|
|
Conflicts:
spec/unit/face/module/install_spec.rb
spec/unit/face/module/list_spec.rb
spec/unit/face/module/uninstall_spec.rb
spec/unit/module_tool/applications/installer_spec.rb
spec/unit/module_tool/applications/uninstaller_spec.rb
spec/unit/module_tool_spec.rb
|
|
|
|
Puppet's config print functionality has a --section option to allow you
to read the configuration as it would be seen in other run modes such as
master or agent. But the environment loaders are provided an
environmentpath and basemodulepath setting prior to Puppet evaluating
the user's --section setting, and will only provide environments as
configured in [main]. So if you have environmentpath set in master, a
`puppet config print modulepath --section master --environment
production` would show you the modulepath for the production
environment as loaded from [main] not [master].
To fix this, when handling a config print call, we are now overriding
the environment loaders with settings obtained from the user selected
section. This means that the interpolated settings can now find an
environment from an environmentpath specified in any section of
puppet.conf.
The static environment loader get_conf() method is also changed to
return a simple configuration that just returns the statically declared
environment's settings. This ensures that `puppet config print
--environment doesnotexist` will correctly print the 'no_manifest' and
empty modulepath setting that reflect the private statically configured
environment settings for a non-existent directory environment.
|
|
* upstream/stable:
(PUP-2158) Unlist configured environment
(PUP-2158) Test dynamic environments with an empty environmentpath
(PUP-2158) Fix integration apply application spec
(PUP-2129) Fix issues with false interpolation start (no-such-method)
(PUP-2158) Report 404 for missing environment
(PUP-2158) Default a missing manifest to no_manifest
(PUP-2158) Hide dir envs behind a feature flag
Conflicts:
lib/puppet/node/environment.rb
spec/unit/environments_spec.rb
|
|
The tests were often creating environments that didn't need to have
manifests. Since we didn't have a way of specifying that when they
were written, we used '' to fill in the blank. This actually caused a
large number of tests to try to find code to load in the PWD, which
caused tests to break if a developer had parse errors in manifests being
used for testing in the root directory of their puppet project. This
changes the manifest to be optional and removes '' from those tests. The
tests no longer fail if a bad manifest is in the PWD :D
|
|
Prior to this commit, the PMT managed all communication with the Forge via the
(now legacy) /v1 API. That API has been deprecated (primarily due to scalability
concerns), which is less of an issue since it was never officially a public API.
This commit migrates all communication to the Forge to the new /v3 API, which is
expected to be launched as our official public API "soon". This commit also
integrates a standalone dependency resolver, as the /v3 API contains no implicit
dependency resolution (as the /v1 API did); consequently, large portions of the
PMT code have been changed, and others have become unreachable.
This commit also changes the default host that the PMT communicates with, from
https://forge.puppetlabs.com to https://forgeapi.puppetlabs.com (the natural
URL for the Forge API service). Since the tool now expects to communicate with
a completely different service, it will be unable to communicate with services
that do not implement the same /v3 API.
|
|
|
|
Adding a 'parallel:spec' task that will group specs and then run those
groups in a parallel set of processes.
By default, parallel:spec will bunch the specs into groups of
approximately 1000 and concurrently run each group up to the number of
processors reported by facter.
The task takes two parameters: process_count and group_size.
Running with a process_count of 1 (parallel:spec[1]) will behave like
the existing 'spec' task, except it will still group the tests and
recycle the spec running process between groups. This has the added
benefit of limiting the spec running process' working set, at the cost
of being a little slower.
|
|
A couple of module_tool specs modified for PUP-1584 were not being
expanded such that they would work properly on Windows or POSIX.
|
|
The module tool was relying on the implicit creation and caching of
legacy environments based on puppet settings for environment and
modulepath. But this does not work for the new directory style of
environments. So we are being explicit about using the current
environment from the context, and overriding modulepath to prepend a
target_dir if given, and then directly inserting the environment to be
used into the options rather than expecting the module_tool applications
to retrieve the correct environment from any other loaders.
Testing is now simpler, but because we are now comparing different but
equal environments, I added equality and hash to node/environment to
facilitate this.
This in turn broke tests, because of
Puppet::Node::Environment#known_resource_types which caches using the
global $known_resource_types. Previously this would always clear itself
when called if $known_resource_types.environment
!= self, but with the new node equality, state was now leaking between
tests. The test_helper now sets $known_resource_types nil after each
test.
|
|
|
|
Both `puppet apply` and `puppet parser validate` were relying on the
legacy environment behavior to implicit draw in the setting of
Puppet[:manifest]. But the new directory environments do not pay
attention to Puppet[:manifest] and thus a call such as `puppet apply
foo.pp --environment dir_env` would not apply foo.pp if dir_env was in
the $environmentpath.
This change explicitly creates a new environment based off the currently
configured environment and overrides with the manifest this to be
applied or validated.
|
|
Instead of creating environments directly, we need to go through the
configured environment loaders, otherwise environments can't come from
other places.
|
|
This moves the global context handling out of the Puppet::Context class
and onto the Puppet module, which allows Puppet::Context to be a more
generic, overridable context system. It also allows references to
context information to be a little bit shorter.
This doesn't tackle making settings information available in the
context, and so there might be a little confusion between Puppet[] and
Puppet.lookup.
|
|
Environments are more than just a name, they are also a modulepath and a
manifest. This commit makes a "create" method for setting up
environments with specific modulepaths and manifests rather than relying
on the Puppet Settings at the time that methods are called. In order to
control environments for module installation they now take advantage of
this in order to control the modulepath that things will be installed
into.
|
|
The "puppet config print" command used to take a special "all"
parameter, but it was lost at some point during the refactoring of the
implementation. This restores the ability to print "all" settings.
|
|
This exposes the lookup facilities that are used inside the settings
infrastructure in a manner that allows looking up values from the
perspective of individual sections. This functionality is then exposed
to the end user as the --section option on the `config print` subcommand.
|
|
The parser face had no spec test coverage. This creates some coverage
around the code. This coverage replaces what is currently being done in
an acceptance test.
|
|
Running specs with rspec 2.13 caused a lot of warnings. Many of them actually
exposed preexisting bugs, the most common being a syntax error when expecting
an Exception. These are worth fixing even if we don't bump to rspec 2.13.
|
|
Previously, the logic for listing and requiring applications was in two
places, CommandLine and Application, respectively.
The CommandLine contained logic, basically duplicated from the
Autoloader, to walk a search path and generate a list unique
applications relative to 'puppet/application'.
The Application contained logic for requiring the application from
'puppet/application', duplicating the logic from CommandLine.
This commit moves the logic for listing available applications to the
Application class, which delegates to its autoloader. Note the
autoloader already takes gem and module paths into account, so no change
in functionality there.
This commit also deprecates the CommandLine available_subcomands
instance and class methods.
|
|
jeffmccune/fix/master/7316_load_faces_from_modulepath_try4"
This reverts commit bdda511d06ed6f89b58343e815585957a33db94e, reversing
changes made to 8f9699cee0d1028d538b0a26aa5bc885751b6d46.
Conflicts:
lib/puppet/settings/config_file.rb
|
|
into 3.x""
This reverts commit ef3fe695fd0be5ff2b5aeb563f34f62a0f503831.
|
|
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,'
|
|
This reverts commit b277bb3874ecd50e1cd6e600bf6d36e3240d5510, reversing
changes made to bdf193640701e9a107b1c6f6661499b31fdefb4d.
These changes are being backed out because they referenced a undefined
methods (`default_global_config_dir` and `default_global_var_dir`).
After fixing that locally, there was still a problem with `puppet help`
printing out a large number of warnings because it could not load face
code correctly.
I think we need to step back from this, re-evaluate what is happening,
and try a new approach.
|
|
This is a "revert-the-revert" commit.
This reverts commit 87ea7a8849f90a232f2bb683fb8a2ce1573a21db, reversing
changes made to 8dff14b9c5a3cdd99ede63dbcbb2dbe00b457926.
|
|
This reverts commit 8dff14b9c5a3cdd99ede63dbcbb2dbe00b457926, reversing
changes made to 8b059a9a9e7c765d3050163ca59abeffe3e297b5.
Revert the modulepath face loader change set for the following reason:
This change set is intended to load faces from the module path. It
works great... _if_ you explicitly set --confdir on the command line
like I do with my zsh puppet() function. If you don't, then it blows up
because the global for the confdir is set by defaults at a different
enough point in the code for us to overlook the issue.
If we invest in removing global state, specifically Puppet.settings, I
think we'll see a very quick return.
The confdir setting should be "available" for use at the same point,
regardless of where it comes from; defaults, puppet.conf, CLI, or
(hopefully) the environment.
|
|
Revert the modulepath face loader change set for the following reason:
This change set is intended to load faces from the module path. It
works great... _if_ you explicitly set --confdir on the command line
like I do with my zsh puppet() function. If you don't, then it blows up
because the global for the confdir is set by defaults at a different
enough point in the code for us to overlook the issue.
If we invest in removing global state, specifically Puppet.settings, I
think we'll see a very quick return.
The confdir setting should be "available" for use at the same point,
regardless of where it comes from; defaults, puppet.conf, CLI, or
(hopefully) the environment.
This reverts commit 8b059a9a9e7c765d3050163ca59abeffe3e297b5, reversing
changes made to 7c3b620182602012b191a5b5ade7b1df5cbc8b19.
|
|
Without this patch the describe blocks are being executed before the
spec helper before hooks. This is problem because the
Puppet::Face.find method now searches the modulepath. The modulepath
setting is not yet initialized when the subject of the describe block is
evaluated.
This patch fixes the problem by explicitly setting the subject inside
the example groups. Doing so delays evaluation of the find method until
after settings have initialized.
I suppose all of this could be summed up as, "Load faces after settings
have been initialized by the spec helper, not before."
Paired-with: Andrew Parker <andy@puppetlabs.com>
|
|
Without this patch Puppet does not search the modulepath lib
subdirectories for application subcommands. This is a problem because
face applications that aren't affected by #3947 should work.
This patch fixes the problem by searching through the modules along the
modulepath to find available subcommands in addition to those available
along the Ruby $LOAD_PATH and RubyGems $GEM_PATH.
Both legacy application files and modern face applications are loaded
from the modulepath with this patch.
This patch does _not_ add the module's `lib/` subdirectory to the
$LOAD_PATH, so issue #3947 will still affect face applications that
attempt to use `require` with library files inside the module.
|
|
In #16189 the problem is described as config print and --configprint
disagree. That problem was caused by the option --mode RUNMODE defined
in FaceBase not having any effect thus making 'user' be the only runmode
available to any Face.
Rather than implementing another way of modifying the run_mode (as
attempted in FaceBase), this commit makes the previously 'read-only'
global setting --run_mode settable from the command line and promotes it
from being a setting to a special case around the loading of settings.
In order to make this global run_mode the default, the Application class
now picks up the default from Settings (where run_mode is handled), and
thus the default becomes either the runmode set from the command line,
or 'user' which Settings has a fallback (default default).
Applications (such as Master) can still set run_mode as part of
application initialization - it works as before.
Unused/non working code relating to this is removed.
Documentation referring to --mode updated.
|
|
https://github.com/joshcooper/puppet into 3.x
|
|
* 2.7.x:
Add Puppet::Parser::Functions::clear for specs
Clear Environment.current when calling Environment.clear
Check that function loading worked correctly.
Avoid stubbing Thread::new due to issues in newer mocha
Rename specs to end in _spec.rb
Don't require mocha in spec_helper
Fix stubbing on nil in some specs
(#14515) Tests fail with mocha 0.11.4
Conflicts:
spec/unit/network/http/webrick_spec.rb
spec/unit/parser/functions/require_spec.rb
spec/unit/parser/functions/template_spec.rb
|
|
|
|
These tests now pass on Windows. Removed the `pending` block and
re-indented, no code changes.
|
|
In rspec 2.11, expectations on a block must take the form of expect...to or
lambda...should. Other combinations of those are no longer accepted. This
commit converts all mixed cases to use expect...to, as it seems to be the
preferred syntax now.
|
|
* 2.7.x:
Use rspec 2.11 compatible block syntax
Conflicts:
spec/integration/faces/ca_spec.rb
spec/integration/network/server/mongrel_spec.rb
spec/unit/application_spec.rb
spec/unit/face/help_spec.rb
spec/unit/network/handler/fileserver_spec.rb
spec/unit/parser/functions/create_resources_spec.rb
spec/unit/provider/nameservice/directoryservice_spec.rb
spec/unit/type/file_spec.rb
spec/unit/type_spec.rb
|
|
In rspec 2.11, expectations on a block must take the form of expect...to or
lambda...should. Other combinations of those are no longer accepted. This
commit converts all mixed cases to use expect...to, as it seems to be the
preferred syntax now.
|
|
Many tests set stubs or expectations on configuration values. This is
unnecessary, as settings are reset before each test. Because creating a stub
stubs out the entire value method on settings, stubbing any individual setting
interferes with retrieving any other setting. This makes for weird errors and
fragile tests. This commit changes most cases to just set each setting
directly.
Expectations on settings were often used to verify that a setting is used.
This is not a good way of testing this, since it checks that the value is
accessed but not that it is actually used correctly. Most expecations on
settings are better expressed by changing the setting and then verifying a
returned value.
|
|
Previously 'puppet module build' required a full path to build a module. This
change will add the ability to run the command from within a module itself
and have the package built correctly.
Through changes to find_module_root it will also support running the command
is a sub-directory of the module as well.
Due to some lack of system and unit testing, I've added that as well as part
of this patch and included tests for the new behaviour.
|
