Ci/validate map.jinja

[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
• [x] [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
• [x] [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

This PR permits to validate the values gathered by map.jinja by:

• adding an openssh._mapdata state, used only for the CI (and the developpers), to generate a /tmp/salt_mapdata_dump.yaml file
• calling that new state in kitchen
• validating the /tmp/salt_mapdata_dump.yaml file against a canonical source

Pillar / config required to test the proposed changes

N/A

Debug log showing how the proposed changes work

  ✔  `map.jinja` YAML dump: should contain the lines
     ✔  File /tmp/salt_mapdata_dump.yaml is expected to exist
     ✔  File /tmp/salt_mapdata_dump.yaml content is expected to include "# yamllint disable rule:indentation rule:line-length\n# Debian-10\n---\nopenssh:\n  absent_dsa_keys:...td: 'no'\n  Subsystem: sftp /usr/lib/openssh/sftp-server\n  UsePAM: 'yes'\n  X11Forwarding: 'yes'\n"

Documentation checklist

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

Testing checklist

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

Additional context

[pull-assistant[bot]]

Best reviewed: commit by commit

---

Optimal code review plan

     test(inspec): share library to access some minion informations      test(inspec): verify `map.jinja` dump      ci(kitchen): execute `_mapdata` state      feat(map): generate a YAML file to validate `map.jinja`

Powered by Pull Assistant. Last update a8d61f4 ... e4ab335. Read the comment docs.

[myii]

@baby-gnu Merged! Really appreciate all of the iterations you went through to get this ready. One of my favourite PRs for a long time!

As a little afterthought (perhaps consider for the next PR after discussing with the others): should we use _mapdata everywhere or is it OK to stick with mapdata in some places? For example, the sub-directory name.

[saltstack-formulas-travis]

:tada: This PR is included in version 1.3.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[baby-gnu]

As a little afterthought (perhaps consider for the next PR after discussing with the others): should we use _mapdata everywhere or is it OK to stick with mapdata in some places? For example, the sub-directory name.

That's an interesting question and I didn't even thought about it when creating the mapdata directory in InSpec profile directory.

I consider the underscore in _mapdata as a notice to users this is something you shouldn't bother, like in Python policy. So outside of user purpose directory the underscore as little meaning to me.

But we could also make it coherent everywhere and it could be renamed quickly to _mapdata. There is no much to do for it ;-)