| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Prior to this commit if you installed a puppet module built on a platform with
a tar implementation that adds PAX headers and your platform didn't have a native
tar implementation (Windows), the module would contain junk PaxHeader directories.
This is due to the default POSIX behavior programmed in to minitar (the ruby tar
implementation used for platforms with out native tar) for an unknown typeflag,
such as those used in PAX headers, is to treat it as a regular file and extract it.
This commit adds a pre-scan step to our use of minitar for unpacking that finds
all the files with standard typeflags (0-7) and then only unpacks those, thus ignoring
any Pax typeflags like 'x' or 'g'.
|
|
|
|
Prior to this change, we’d attempted to handle shell escaping of
arguments by passing arrays of arguments rather than a single full
command string. While this worked as intended, it meant that we needed
to stream data between processes through Ruby. As it happens, larger
tarballs would cause the write pipeline to become backed up, and since
we would attempt to write all the data before reading any, we would
effectively deadlock.
Rather than attempting to stream by chunks, we’ve reverted back to using
the full string commands, and managing shell escapes (where needed) in
Ruby.
|
|
The Gnu tar implementation executes `tar cf - #{sourcedir}`, which can be a
relative path. So it is not necessary to expand it, and doing so causes the
test to fail on windows.
|
|
Prior to this commit, the specs made assertions about absolute file
paths, which works perfectly until you try running the tests under
Windows. This change patches the tests so that they will continue to
run properly under both Windows and Linux.
|
|
In the previous commit, the default behavior of `execpipe` was changed
to ensure that the pipe was always opened in read/write mode. While we
aren't aware of any regressions this change would cause, the cautious
route is to maintain the same default behavior for now; to that end,
this commit adds a `mode` parameter to `execpipe`, allowing callers to
choose the mode the pipe is opened in.
|
|
Prior to this commit, if the module_working_dir or the path to a module
being built contained whitespace, our simple string-interpolation
would fail to create a valid call to `tar` or `gzip`. This change fixes
the bugs resulting from that behavior.
|
|
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.
|
|
Changes to the way Puppet::ModuleTool::Tar::Gnu works means that the
*::Tar::Solaris variant should now be redundant. It existed to require
gtar when the underlying platform did not support GNU-tar options, but
the changes to the core Tar::Gnu class mean that we no longer use any
flags or options that don't work just fine with oldschool unix tar
executables. Remove Puppet::ModuleTool::Tar::Solaris.
On a side note, Tar::Gnu should probably be renamed to something more
generic.
|
|
I'm not entirely sure if I'm using #yields() correctly but this allows
me to expect that Dir.chdir is called, and still expect all the calls to
Puppet::Util::Execution.execute to be made.
|
|
|
|
|
|
Previously, modules installed by the root user would retain the
original group membership information. This change ensures that the
group will match the module directory being installed to.
|
|
This test wasn't updated when the signature of #unpack was changed, which was
causing the tests to fail. The test now sends appropriate arguments to
the method.
|
|
Prior to this change, tarballs unpacked by the root user would be unpacked
with the permissions and the ownership information present in the tarball.
In the best case, this made some modules fail to function after installation
since the newly installed module was owned by a different user. In the worst
case, this could be seen as a fairly serious security vulnerability.
This change ensures that the module's permissions are always owner-writable,
world-readable, and that the owner is always the same as the module's parent
directory.
|
|
cd4d720 fixed the issue with `puppet module build` on Solaris, but did
not update the spec test to reflect the new command being executed.
This patch updates the spec test.
|
|
Without this patch `puppet module build` produces an empty tar file when
run on Solaris. This is obviously a problem. The root cause is that
tar defaults to writing the archive to the tape device instead of STDOUT
as was expected.
This patch fixes the problem by explicitly using `tar cf - ...` to write
the archive to STDOUT.
Paired-with: Andrew Parker <andy@puppetlabs.com>
|
|
Previously, the module tool relied on GNU versions of tar and gzip/gunzip
to build and install modules, which isn't portable on Windows in
particular.
This commit adds Gnu, Solaris, and Mini tar implementations for packing
and unpacking tar.gz format.
It modifies the module tool to select the appropriate implementation for
the platform it's currently running on.
Paired-with: Andy Parker <andy@puppetlabs.com>
|
