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

Ansiblecheck Integration #170

Merged
merged 2 commits into from
Nov 11, 2016
Merged

Ansiblecheck Integration #170

merged 2 commits into from
Nov 11, 2016

Conversation

ChristopherDavenport
Copy link
Contributor

Created variables for initialization while retaining all extant functionality. The first tests run exactly as before where new tests now run in containers specific to operating systems. setup.yml was created to demonstrate required base packages off of the bare images.

Should be a more rubust testing system now that works easily with travis-ci. AnsibleCheck allows for testing roles against multiple operating systems and as testing shows you have gained proof it works in other environments while sacrificing none of your original testing.

I'd be glad to make any changes to suit what works best for you but I wanted to make this available to you.

Created variables for initialization while retaining all extant functionality. The first tests run exactly as before where new test now run in containers specific to operating systems. setup.yml was created to demonstrate required base packages off of bare image. 

Should be a more rubust testing system now that works easily with travis-ci.
@ricardclau
Copy link
Member

Wow this is fantastic, it was on my to-do lists as we were only testing ubuntu at the moment!

Thanks, will review and add comments!

@ricardclau
Copy link
Member

Why not supply a boolean environment variable to ansible-playbook and load setup.yml depending on that so that there is only one main.yml file and not 2?

@ChristopherDavenport
Copy link
Contributor Author

The difficulty I have with that approach is that the syntax check on 1.9 does not recognize the package command, which was introduced in 2.0. So that was the easy way out. I am now attempting a build with apt and yum with when clauses, and when support for 1.9 goes away it can get to a more dry implementation.

Removing specific vars and the package function we get a more verbose but resilient for 1.9 version that will work for the original test conditions and the docker test conditions and guarantees that builds are effectively equivalent as some plays don't only run for the containerized version
@ChristopherDavenport
Copy link
Contributor Author

So I opted for a setup script that makes sure that those essentials are installed regardless of the testing system including your previous builds. It seems to me as though in general it will be a more sound testing strategy than running separate tests depending on the environment. It also vastly reduces the footprint of the change, as now it amounts to the edits to .travis.yml and the new setup playbook. Also, I mirrored the -v that was in the original tests so that the containerized output would be matching as much as possible.

@ricardclau
Copy link
Member

Yeah, that makes sense. Packages like git and subversion are installed in the default travis ubuntu image so this will not change a thing and it will add them in other environments :)

We just merged a long standing PR regarding git submodules, will review a bit more tomorrow (EU time) and merge it, thanks a lot for this contribution!

@ricardclau ricardclau merged commit 84a7ce1 into ansistrano:master Nov 11, 2016
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.

2 participants