-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tarball #1244
Tarball #1244
Conversation
c9159b3
to
1ee9767
Compare
It's not just a development dependency; it's an r10k dependency too. Really it always has been because it's a puppetforge dependency.
1d73966
to
bd759f7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I want to play with this a bit.
Would you mind adding something to the docs with examples on how to use this? |
# @return [Array<String>] | ||
def desired_contents | ||
desired = [] | ||
desired += @tarball.paths.map { |entry| File.join(@full_path, entry) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discovered an interesting edge case here: if you build the tarball a bit wrong, even though it unpacks correctly, it might purge incorrectly. In my case, I created the tarball with .
. So the paths inside it look like this:
"/Users/aileen/code/r10k/yaml-envs/tarball/.",
"/Users/aileen/code/r10k/yaml-envs/tarball/./site-modules",
"/Users/aileen/code/r10k/yaml-envs/tarball/./hiera.yaml",
...
But r10k's current_contents
list looks like this:
"/Users/aileen/code/r10k/yaml-envs/tarball/site-modules",
"/Users/aileen/code/r10k/yaml-envs/tarball/hiera.yaml",
...
So it purges everything except the modules
directory (which is ignored by the environment
purge level).
I realize this was my mistake, and I should get better at tarballs 😛 But it seems like something that could trip people up and cause a very confusing bug. Maybe we can add some normalization in Tarball.paths
? Adding Pathname.new(path).cleanpath
seemed to do the trick for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha! Excellent catch. Although I do have unbridled confidence that users of software would NEVER imperfectly construct a tarball 😉, this does seem like something we could fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh. I just snap-pushed what I thought would be the fix in 5a1711e, and then realized I was looking at a completely different part of the code. But, it might actually be a valid fix anyway? Don't have a test for it yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the spot I edited when fixing this locally 🤷♀️ Seemed to work for my bad tarball.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were you working on a test for this? I think besides that, I'm happy to merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, lemme add some thing for that. I might just re-construct the fixture tarball to include the ./
name components, I think that'd make it easy to validate. Will push something shortly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's what I was thinking 🙂
So, are the tarball modules usable from the Puppetfile too? Or just with yaml envs? If they are usable from a Puppetfile, it might be nice to note that here. |
Totally, and yeah, they are usable. I believe bc24f6b contains some reference to that. Do you think it should say more or say it differently? |
Oh duh, no, I missed which file that got added to, my bad. |
5a1711e
to
a059c4c
Compare
This class will serve as a base class for creating tarball environment and module types.
Trying to make sure the global cachedir option gets respected by tarball
This permits modules of type tarball to be used. Tarball modules will be extracted with no modification into the modules target directory. Tarballs should not be packed to include a top-level containing folder. modules: lwf-remote_file: type: tarball source: https://forge.puppet.com/v3/files/lwf-remote_file-1.1.3.tar.gz version: bce01b849631926b452900eff5dc385c893c4320c95b290f992e3c529f417f0e
This permits core environment content to be sourced from tarballs. The tarball environment type supports defining modules as well. --- production: type: tarball source: https://example.com/puppet-code-env-1.0.0.tar.gz version: 99a906c99c2f144de43f2ae500509a7474ed11c583fb623efa8e5b377a3157f0
Co-authored-by: Maggie Dreyer <maggie@puppet.com>
Users might construct a tarball with entries like this: ./ ./foo.txt ./foo/bar/ r10k's purging facility needs these to be normalized to work correctly. This commit makes the R10K::Tarball#paths method normalize the values to e.g. foo.txt foo/bar Co-authored-by: Maggie Dreyer <maggie@puppet.com>
a059c4c
to
7f1683d
Compare
Two logical changes:
I didn't go so far as adding a purge test specifically. Seems like the most thorough fix would actually be to R10K::Util::Purgable itself, if we really wanted to do that. It seems reasonable enough for Tarball to just make sure paths returned are clean paths. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Retested this, seems to work well.
lib/r10k/module/tarball.rb
Outdated
def properties | ||
{ | ||
:expected => @checksum, | ||
:actual => status, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be something like :insync
, :absent
, :mismatch
, right? I think consumers of this (for existing modules) determine the status of insync/mismatch/absent from whether the actual equals the expected, or if it differs, and if it differs if the actual was nil, respectively. I think we want to continue that behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better? e783dcc
I'm not actually sure how/where/why #properties is used, or what expectations exist for this method. The YARDoc definition in R10K::Module::Base isn't super helpful on that front.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are collected to write the r10k-deploy.json, which is used by Impact Analysis.
When a module is insync, the module's `actual` and `expected` properties should match. When the module is not in sync, they should differ.
Chunk PR in support of (original monster PR) #1159
This pull request DEPENDS ON #1242, #1243. Do not merge until after those PRs are merged.
This PR implements:
Example usage:
Later enhancements built on top of this might include Artifactory types, or S3 types, with options for real versions, depending on how the remote repository works.
Fixes #567
Closes #1159