style(inspec): match current practices for file and control names

[baby-gnu]

PR progress checklist (to be filled in by reviewers)

• Changes to documentation are appropriate (or tick if not required)
• Changes to tests are appropriate (or tick if not required)
• Reviews completed

---

What type of PR is this?

Primary type

• [build] Changes related to the build system
• [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ci] Changes to the continuous integration configuration
• [feat] A new feature
• [fix] A bug fix
• [perf] A code change that improves performance
• [refactor] A code change that neither fixes a bug nor adds a feature
• [revert] A change used to revert a previous commit
• [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [docs] Documentation changes
• [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

Describe the changes you're proposing

I don't find a reference best practices in the documentation but:

• the _spec in the control file name is inherited from RSpec and few examples use it

• the control name should be an identifier, I matched the tpldot name

• the title is a human readable description of the control

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Now the output looks like this:

  ✔  TEMPLATE.config.file: verify the template-formula.conf lines
     ✔  File /etc/template-formula.conf is expected to be file
     ✔  File /etc/template-formula.conf is expected to be owned by "root"
     […]	 	 
  ✔  TEMPLATE.subcomponent.config.file: verify the subcomponent configuration file
     ✔  File /etc/TEMPLATE-subcomponent-formula.conf is expected to be file
     ✔  File /etc/TEMPLATE-subcomponent-formula.conf is expected to be owned by "root"
     […]

  ✔  TEMPLATE._mapdata: `map.jinja` should match the reference file
     ✔  File /tmp/salt_mapdata_dump.yaml is expected to exist
     ✔  File /tmp/salt_mapdata_dump.yaml content is expected to eq "# yamllint disable rule:indentation rule:line-length\n# CentOS Linux-8\n---\nadded_in_defaults: defa...ATE-subcomponent-config-file-file-managed:\n    - subcomponent-example.tmpl.jinja\nwinner: pillar\n"
  ✔  TEMPLATE.package.install: required package should be installed
     ✔  System Package bash is expected to be installed
  ✔  TEMPLATE.service.running: the service should be running and enabled
     ✔  Service systemd-journald is expected to be installed
     ✔  Service systemd-journald is expected to be enabled
     ✔  Service systemd-journald is expected to be running

Documentation checklist

• Updated the README (e.g. Available states).
• Updated pillar.example.

Testing checklist

• Included in Kitchen (i.e. under state_top).
• Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• Updated the relevant test pillar.

Additional context

We spoke abouth this in Salt Formula Working Group 2020-09-08

[daks]

At work, we also use Inspec like it was/is (except for the filename which has no real sense in fact) before this PR. Do other changes comes from Inspec own documentation?

[baby-gnu]

Do other changes comes from Inspec own documentation?

I don't really found guidelines to write control files, I mostly took the comments from the WG meeting and the examples.

[daks]

Do other changes comes from Inspec own documentation?

I don't really found guidelines to write control files, I mostly took the comments from the WG meeting and the examples.

Looks fine, but I'm not sure there is any 'standard', first file opened https://github.com/inspec/inspec/blob/master/examples/kitchen-chef/test/integration/default/web_spec.rb :) with a title and control which forms a complete sentence.

[myii]

Thanks for going to this effort, @baby-gnu. Nice to see working group items getting tackled. I'm pretty happy with the changes, unless we can find some official guidelines for how to make these adjustments.

By the way, this also reminded me that we have this user story in Taiga, to propose adding some kitchen-salt examples to that repo (via. the kitchen-inspec README):

• https://tree.taiga.io/project/myii-saltstack-formulas/us/50

[baby-gnu]

Looks fine, but I'm not sure there is any 'standard', first file opened https://github.com/inspec/inspec/blob/master/examples/kitchen-chef/test/integration/default/web_spec.rb :) with a title and control which forms a complete sentence.

You're right @daks and then I found things like this and the counter example in the same directory 🤪

[dafyddj]

As the one who brought this up in the WG, here is what my comments were based on: Chef InSpec Profile Style Guide

[myii]

Thanks, @baby-gnu, I'm good with this. Just a minor suggestion offered.

Any further concerns or suggestions, @daks, @dafyddj?

[dafyddj]

Perhaps I'm being pedantic but just making some suggestions for tidiness/consistency.

[myii]

Thanks @baby-gnu.

@dafyddj If you're happy with this, feel free to merge it.

[saltstack-formulas-travis]

🎉 This PR is included in version 4.3.7 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[myii]

Changes have been propagated to all formulas using myii/ssf-formula#292.

[myii]

Changes have been propagated to all formulas using myii/ssf-formula#292.

Note, this means that _mapdata_spec.rb is renamed to _mapdata.rb in all formulas but the rest of the InSpec files will still have the _spec in them. I did contemplate adding a little script to the PR, so that these would be automatically fixed as well but I felt that was a little too much to push through in one go. Any thoughts on a cleaner way to do this or shall we just fix them in each formula manually, in due course?