Skip to content
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

Update acceptance tests, add EPEL test case for RedHat acceptance tests #308

Merged
merged 2 commits into from
Sep 9, 2017
Merged

Update acceptance tests, add EPEL test case for RedHat acceptance tests #308

merged 2 commits into from
Sep 9, 2017

Conversation

wyardley
Copy link
Contributor

@wyardley wyardley commented Sep 7, 2017

This does a few things:

  1. Updates spec_helper_acceptance to use puppet_install_helper
  2. Updates .travis.yml / .sync.yml to run acceptance tests in CI (CentOS 7 and Ubuntu 14)
  3. Verifies some extra stuff, including the package source. This will fail as of now, because of the problem mentioned in EPEL now has dependency on http-parser #307 / https://bugzilla.redhat.com/show_bug.cgi?id=1481008

There are still some issues that running these tests exposes. It seems like Ubuntu 16.04 installs the Ubuntu version of nodejs vs. the nodesource one; I'm not trying to fix that one (or test for it) here.

@wyardley wyardley requested a review from bastelfreak September 7, 2017 05:50
.travis.yml Outdated
env: PUPPET_INSTALL_TYPE=agent BEAKER_debug=true BEAKER_set=docker/centos-7 CHECK=beaker
services: docker
sudo: required
- rvm: 2.1.9
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use 2.4.1 here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that it's updated in modulesync, I'll give it a shot as an extra test.

@@ -1,3 +1,6 @@
---
.travis.yml:
secure: "SCQpiBB9qpZAjBRk+b9D3cSCQfYpDgHPOdOc7djfGeB5yn1UbGg7uW1zshrshb4QMLfUgvsL4LsT0CYj7ilBerghgeySF5JWuZdk05W/7Iudls4btbxdVjqtALR7p02mnk40qHTR1Tdb/j0gXW9uigU6nQU9iCP+Poa1KF6PXpk="
docker_sets:
- set: docker/ubuntu-14.04
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does 16.04 also work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

16.04 fails if we want the source to be nodesource, as it seems like it's supposed to be:
https://github.com/voxpupuli/puppet-nodejs/blob/master/manifests/params.pp#L86
16.04 gives me:

Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>

I'm not sure if that's a bug (probably because Ubuntu 16 version is > nodesource one), or if it's intentional. If it's intentional, we could do some logic to look for different expected package sources depending on vendor.

Debian 82 did work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ps - before the updates to spec_helper_acceptance, the tests were failing completely on multiple platforms, so this at least is an improvement, I think. Once we know what the expected behavior is, we can figure out how the tests should be (and if any fixes are needed in the actual module code).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add debian 8? Does 9 work as well

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an additional one, or instead of Ubuntu?
FWIW, I don't think modulesync provides Debian 9 yet, and I don't see it in the rake tasks
https://github.com/voxpupuli/modulesync_config/tree/master/moduleroot/spec/acceptance/nodesets

@wyardley
Copy link
Contributor Author

wyardley commented Sep 7, 2017

ps - the failed test on CentOS 7 is expected (for now).

Class['epel'] -> Class['nodejs']
}
EOS
# Run it twice and test for idempotency
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this too, but can't use shared examples in an 'it' block, and maybe overkill to use within the same file? I am going to switch to the catch_failures / catch_changes pattern and simplify things a bit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

expect(apply_manifest(pp, catch_failures: true).exit_code).to be_zero
end

if fact('os.family') == 'RedHat' || fact('os.family') == 'Debian'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use ['RedHat', 'Debian'].include? fact('os.family') then you only need to get the fact once. Since it's retrieved from the VM/container over SSH this might be a good thing to consider.

end

context 'repo_class => epel' do
if fact('os.family') == 'RedHat'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you squash this into the context: context 'repo_class => epel', if: fact('os.family') == 'RedHat' do (note that I'm not 100% sure this works so please test it)

@wyardley
Copy link
Contributor Author

wyardley commented Sep 7, 2017

@ekohl @bastelfreak - How does that look now? I think I've addressed most of your (very helpful) feedback.
The tests now pass except for the expected failure.

class { 'nodejs':
repo_class => '::epel',
}
class { 'epel': }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these 2 lines are redundant (or should be):

include $repo_class
anchor { '::nodejs::begin': }
-> Class[$repo_class]
-> Class['::nodejs::install']

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure about the history of that, so was hesitant to yank it otu; I will see if the test still works Ok with that removed, though, and commit if so.

We should also switch to 'contain' vs. anchor pattern (can do this in a separate PR)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also switch to 'contain' vs. anchor pattern (can do this in a separate PR)

+1

@wyardley
Copy link
Contributor Author

wyardley commented Sep 7, 2017

In most recent push, I set the failing part as pending, we could then take the pending line out when CentOS 7.4 comes out?

@wyardley
Copy link
Contributor Author

wyardley commented Sep 8, 2017

@ekohl: how's it look now?

@@ -31,7 +17,6 @@
# Install module and dependencies
hosts.each do |host|
copy_module_to(host, source: proj_root, module_name: 'nodejs')
shell("/bin/touch #{default['puppetpath']}/hiera.yaml")
on host, puppet('module install puppetlabs-apt --version 2.0.1'), acceptable_exit_codes: [0, 1]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we remove the version foo here to get the latest?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd consider https://github.com/puppetlabs/beaker-module_install_helper since that also takes are of the copy_module_to line above if you're going to fix that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine, I improved it and now you want more improvements? 😛 Ok, sold

context 'default parameters' do
let(:pp) { "class { 'nodejs': }" }

it 'runs successfully' do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add the shared example for this but I can submit a PR for that later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, I didn't spend too long trying to get it to work (it wouldn't work inside an 'it' block).
I did see someone else create a self.foo in a test, and then use that where they wanted to reuse an item in the same test (vs. across different files).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trick is that it already contains it blocks so you don't need that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wyardley
Copy link
Contributor Author

wyardley commented Sep 9, 2017

Updated to use module_install_helper

@wyardley wyardley merged commit 56a6155 into voxpupuli:master Sep 9, 2017
@wyardley wyardley deleted the update_acceptance_tests branch September 9, 2017 23:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants