Closed Cinderhaze closed 8 years ago
Hello:
What's the status of this PR? Is it still needed?
Sorry, I forgot about this. I had forked the module, and made this modification and wanted to share it with the community. Are there any additional steps that I would need to take, or any further review needed?
@Cinderhaze thanks for the PR. Could you add a rspec test for this functionality?
I just cloned the main project, ran bundle install from the module directory, and ran 'spec'. I'm seeing
Finished in 40.04 seconds (files took 2.79 seconds to load) 47 examples, 31 failures
I'm new to writing rspec tests (though I've been working with puppet for about a year)
I see above that all checks have passed above, Is there something I should be doing differently to run the tests?
Thanks for your help
@Cinderhaze Run the following:
gem install bundler
bundle install
bundle exec rake spec
You should see the tests passing after that! :smile:
Thanks @petems.
I was able to get the tests to run with your help. They run and build locally.
I wasn't sure if I should add a case for the failure condition. I need to figure out the syntax to express the case of
describe 'fail when deploying tar.gz with filename in title and no source' do let(:title) { 'sample.tar.gz' } let(:params) {{ :target => '/usr/local' }} it { should fail() } end
Also, I know there is a defined class to get the 'basename' from the file path, but that doesn't give me the logic to detect if it is only a filename or if it's a full path. If it's preferable, I could modify the conditional and use the staging_parse($name, 'basename')
method
It looks like the travis checks failed with
NoMethodError: undefined method
spec' for nil:NilClass
An error occurred while installing bodeco_module_helper (0.1.0), and Bundler`
I don't think that's a result of my change. Is one of my other files out of date? Do I need to re-merge from your master branch?
Did any info come out of #88 as to why Travis seems to be unhappy?
Can you rebase against the current master and squash? Travis may be happier then.
I had already merged master into my branch hoping that would fix it.... You want me to rollback HEAD to before the merge, rebase to master and squash?
Same problem as every other time..
NoMethodError: undefined method `spec' for nil:NilClass An error occurred while installing bodeco_module_helper (0.1.0), and Bundler cannot continue.
I'm out of ideas. Tagging @danzilio and @daenney.
It needs some cleaning up in the tests. I don't think that bodeco_module_spechelper
thing is still really a thing and not something we're using in other places either.
Can you rebase against the current master?
I rebased, and ran bundle install before attempting to run the tests locally.. I see the following in both my rebased version and my upstream/master
Installing fission 0.5.0 Invalid gemspec in [/var/lib/gems/1.9.1/specifications/unicode-display_width-1.0.2.gemspec]: Illformed requirement ["< 3.0.0, >= 1.9.3"] Installing launchy 2.4.3 Invalid gemspec in [/var/lib/gems/1.9.1/specifications/unicode-display_width-1.0.2.gemspec]: Illformed requirement ["< 3.0.0, >= 1.9.3"] Installing parser 2.3.0.6 Invalid gemspec in [/var/lib/gems/1.9.1/specifications/unicode-display_width-1.0.2.gemspec]: Illformed requirement ["< 3.0.0, >= 1.9.3"] Installing jgrep 1.4.0 Invalid gemspec in [/var/lib/gems/1.9.1/specifications/unicode-display_width-1.0.2.gemspec]: Illformed requirement ["< 3.0.0, >= 1.9.3"] Installing spdx-licenses 1.0.0 Invalid gemspec in [/var/lib/gems/1.9.1/specifications/unicode-display_width-1.0.2.gemspec]: Illformed requirement ["< 3.0.0, >= 1.9.3"] Installing travis-lint 2.0.0 Invalid gemspec in [/var/lib/gems/1.9.1/specifications/unicode-display_width-1.0.2.gemspec]: Illformed requirement ["< 3.0.0, >= 1.9.3"] .... etc..
That seems like a problem with the upstream gem. I'll see who I can ping.
I'm not sure how to tell it to pin to 1.0.1 to test it out, but I saw this in the commit going from 1.0.1 to 1.0.2
Looking a bit deeper at the issue referenced by that checkin..
https://github.com/janlelis/unicode-display_width/issues/6
The Vagrant image I was using to run my tests is using ruby 1.9.3, which isn't officially supported by that gem.
My nokogiri gem is also failing to build. I'll try moving to a more modern toolchain
@Cinderhaze after the gem name in the gemfile, add , 'version'. There are other examples in the Gemfile. If that works locally, let us know and we'll merge.
Hi @Cinderhaze, thanks for the PR! Could you please take a look at the comment from @jyaworski?
Oh, sorry I didn't get back to you. It didn't seem to work, but I was going down a bit of a rabbit hole with the changes to one of the dependencies to guard, which caused it to require ruby 2.2 or 2.4, and I wasn't able to get my system able to fully resolve everything, including using the version portion. That was supposed to work with a prerelase version of bundler to have it limit the gems to what your ruby version could handle.
I'll give it another try and see if some of the versioning changes have have resolved the situation. There is also the new LTS build of ubuntu (16.04), so I'll try it on there.
It looks like after fixing linting errors, there are rubocop errors for the ruby 2.3 tests and the second jruby test shows..
Comparing Symbols to non-Symbol values is deprecated (file & line not available)
How should I proceed with this?
please rebase. I just did https://github.com/voxpupuli/puppet-staging/pull/97 which updated the module and fixed rubocop issues.
Ok, looks like I just need to get my patch up to the rubocop standards, then this should work.
Thanks to everyone for helping me through this process!
Get alllllll the gems:
bundle install --path .vendor/ --without system_tests development
List all the rubocop things:
bundle exec rubocp -c .rubocop.yml -D
fix them:
bundle exec rubocp -c .rubocop.yml -D -a
That's pretty cool. I really need to get better acquainted with the ruby ecosystem.
thanks for the fix. If you've any questions regarding ruby, puppet, development tool or good rants about awful software, join #voxpupuli on freenode, we're always happy to help.
I was using your module, and I noticed that if you pass in the full path to staging::deploy, it tries to use the full url as the name, which causes the file to be put in nested directories under the default stage.
When staging::extract is looking for the file, it looks where you would expect the file to be, but not where deploy puts it.
Thanks for considering my PR!