| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Prior to this commit, there were a number of places where documentation
was missing and test names were insufficiently descriptive. This commit
adds additional clarity around those places, and makes a couple of code
clarity changes as well.
|
|
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.
|
|
* pr/2322:
(PUP-1563) Don't recurse when dependencies are empty
(PUP-1563) resolve_install_conflicts excessively recurses
Closes GH-2322
|
|
Previously we would recurse for each leaf dependency unnecessarily.
This commit ensures we only recurse if we have a non-empty set of
dependencies, and adds a debug message when conflicts are checked.
It also adds a spec tests to ensure we evaluate each module for
conflicts only once.
Paired-with: Josh Partlow <joshua.partlow@puppetlabs.com>
|
|
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.
|
|
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.
|
|
|
|
|
|
This commit allows the module tool to run on windows and updates the spec
tests as they are no longer pending.
|
|
In the 2.7 series, we used the fails_on_windows rspec filter to
exclude unit tests on windows.
In 3.x, that approach has been removed. Instead, if the test should
never be expected to pass on Windows, then use an exclude filter like:
describe Puppet::MyClass, :unless => Puppet.features.microsoft_windows? do
However, if the test doesn't currently pass, but should sometime in
the future, then use an rspec conditional pending block:
pending("porting to Windows", :if => Puppet.features.microsoft_windows?) do
<example1>
end
|
|
When creating the install path, if there is a file in the way then there
was an unhandled exception. This commit extracts out a install directory
handling code for ease of testing and adds handling for this case.
This class excapsulates the logic of preparing the installation
directory for modules. As we find more operations on the installation
directory we should try to move them to this class.
|
|
Without this patch, the puppet module install command will fail when run
as a normal user account without a ~/.puppet directory.
The error is:
$ puppet module install puppetlabs-cloud_provisioner
Preparing to install into /Users/jeff/.puppet/modules ...
Error: Could not install module 'puppetlabs-cloud_provisioner' (latest)
Directory /Users/jeff/.puppet/modules does not exist
This is a problem because it adds friction to the process of getting started
with Puppet.
This patch fixes the problem by creating the directory if the path does not
already exist. If the path does exist, then the error is still thrown, but has
been modified slightly to provide helpful next actions. The error when the
path exists as a non-directory looks like:
Error: Could not install module 'puppetlabs-cloud_provisioner' (latest)
The reason is path '/Users/jeff/.puppet/modules' is not a directory.
A potential solution is `mkdir -p '/Users/jeff/.puppet/modules'`.
This patch also handles the situation where the target path does not exist but
the effective uid of the puppet process does not have access to create the
directory. The error message in this case looks like:
Error: Could not install module 'puppetlabs-cloud_provisioner' (latest)
Permission is denied when trying to create directory '/Users/jeff/.puppet/modules'.
A potential solution is to check the ownership and permissions of parent directories.
|
|
The User-Agent will provide the server with some information
about the version of the module tool, the version of puppet, and the
version of ruby that is being used.
This commit also ensures that Puppet::Forge does not depend on the
Puppet::Face code. In order to achieve that the module face now is
responsible for creating the correct Puppet::Forge object and handing
that to the various components of the face for execution.
The Puppet::Face now provides an interface for interacting with the
repository in ways that various users were doing by asking for the
repository directly.
|
|
This manually fixes up a pile of Puppet Module Tool conflicts by hand, related
to overlapping changes with nothing but textual translation. The rest of the
merge was smooth and simple.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
Without this patch, Puppet will monkey patch the existing implementation
of the puppet-module Gem if it is used. This is bad because the two
implementations are all jumbled up inside of one another and behavior
may become unpredictable. Warnings are also displayed directly to the
end user in the form of redefined constants.
This patch fixes the problem by renaming Puppet::Module::Tool inside of
Puppet to Puppet::ModuleTool This fixes the problem because Puppet will
no longer monkey-patch the Puppet::Module::Tool module inside of the
puppet-module Gem.
This patch also has the added benefit of making the Module's name match
up with the CamelCase filepath (puppet/module_tool/ =>
Puppet::ModuleTool) As a result, no file moves are necessary.
|
|
A whole bunch of tests scattered through the system fail on Windows, around
features that are not supported on that platform. (They are things that only
the master does, which an agent-only platform doesn't need to support.)
These were tagged `fails_on_windows` to allow filtering them from rspec runs,
which is great, but doesn't actually communicate nearly as much useful
information as it would if we used the "conditionally pending" facilities that
rspec has supported since 2.3.
That gives us two key things: one, it works automatically based on our
knowledge of the platform, which means you can't forget to turn off failing
tests.
Two, it means that if the test starts unexpectedly passing we also get a
failure, since we should respond to "works when it shouldn't" as seriously as
"fails when it shouldn't".
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
This rather large commit includes all the work needed to get the `puppet
module` face in Puppet with all it's actions. I tried to break this up
into smaller commits, but it was difficult to do so and keep the
individual commits in a state that had passing specs since many changes
in shared module_tool code affected multiple actions. This code was
developed in an integration branch over a few montsh and is now being
merged back into Puppet core in the same state that shipped with Puppet
Enterprise 2.5.
The work here was done by Pieter van de Bruggen <pieter@puppetlabs.com>,
Kelsey Hightower <kelsey@puppetlabs.com> and myself.
|
