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

Document Serverspec Migration #804

Closed
chris-rock opened this issue Jun 23, 2016 · 5 comments · Fixed by #1368
Closed

Document Serverspec Migration #804

chris-rock opened this issue Jun 23, 2016 · 5 comments · Fixed by #1368
Assignees
Labels
Aspect: Docs Write the Fine Manual
Milestone

Comments

@chris-rock
Copy link
Contributor

Description

InSpec inherits a lot of similarities to Serverspec, especially the Syntax is very similar and most Serverspec resources are available in InSpec as well #514

Nevertheless, InSpec and Serverspec have some differences

  • InSpec is promoting a flat test structure instead of nested describe blocks
  • No clear guide is available that helps users to easily migrate: Question: Where is the serverspec migration guide? #514
  • We should add a warning, if we detect Serverspec syntax that we do not support (e.g. nested describes)

InSpec and Platform Version

InSpec 0.26.0

@chris-rock chris-rock added the Aspect: Docs Write the Fine Manual label Jun 23, 2016
@rmoriz
Copy link

rmoriz commented Jun 23, 2016

The big issue with inspec is its incompatibility with common rspec patterns, not only nested describe blocks but also common things like let.

You should point users to at least three chef-cookbooks that, in your opinion, provide a good overview about the use of inspec in real-life. Sadly, "complicated" cookbooks that show advanced real-life usage of chef, seem still to use serverspec (e.g. Jenkins, iptables)

@rmoriz
Copy link

rmoriz commented Jun 23, 2016

@chris-rock let's say we have to verify the installation of a given android-ndk release, like "11c" - Usually I would specify the version number in one place and re-use the variable in subsequent tests, so once we upgrade, I only need to change one variable.

I know your hardening cookbooks but they are not "full lifecycle" cookbooks with a complexcity and "wrappability" like the mentioned iptables and jenkins cookbooks.

@chris-rock
Copy link
Contributor Author

@rmoriz Got you. Why not use a plain ruby variable? I just try to understand, what the need is. Implementation details are following the understanding of the need ;-)

@chris-rock
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Aspect: Docs Write the Fine Manual
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants