chore: use semantic-release cross-formula standard structure

* Automated using `ssf-formula` (v0.1.0-rc.2)

Author: myii

.gitignore

@@ -48,6 +48,7 @@ coverage.xml
 .kitchen
 .kitchen.local.yml
 kitchen.local.yml
+junit-*.xml
 
 # Translations
 *.mo
@@ -103,5 +104,19 @@ ENV/
 # mypy
 .mypy_cache/
 
+# Bundler
+Gemfile.lock
+
 # copied `.md` files used for conversion to `.rst` using `m2r`
 docs/*.md
+
+# Vim
+*.sw?
+
+## Collected when centralising formulas (check and sort)
+# `collectd-formula`
+.pytest_cache/
+/.idea/
+Dockerfile.*_*
+ignore/
+tmp/

.travis.yml

@@ -1,3 +1,6 @@
+# -*- coding: utf-8 -*-
+# vim: ft=yaml
+---
 stages:
   - test
   - commitlint
@@ -7,6 +10,7 @@ stages:
 sudo: required
 cache: bundler
 language: ruby
+dist: xenial
 
 services:
   - docker
@@ -29,19 +33,15 @@ env:
     # - INSTANCE: default-ubuntu-1604-2018-3-py2
     # - INSTANCE: default-centos-7-2018-3-py2
     # - INSTANCE: default-fedora-29-2018-3-py2
-    # TODO: Use this when fixed instead of `opensuse-leap-42`
-    # Ref: https://github.com/netmanagers/salt-image-builder/issues/2
-    # - INSTANCE: default-opensuse-leap-15-2018-3-py2
     - INSTANCE: default-opensuse-leap-42-2018-3-py2
     # - INSTANCE: default-debian-8-2017-7-py2
     # - INSTANCE: default-ubuntu-1604-2017-7-py2
-    # TODO: Enable after improving the formula to work with other than `systemd`
     - INSTANCE: default-centos-6-2017-7-py2
     # - INSTANCE: default-fedora-28-2017-7-py2
     # - INSTANCE: default-opensuse-leap-42-2017-7-py2
 
 script:
-  - bundle exec kitchen verify ${INSTANCE}
+  - bin/kitchen verify ${INSTANCE}
 
 jobs:
   include:

bin/kitchen

@@ -0,0 +1,29 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+#
+# This file was generated by Bundler.
+#
+# The application 'kitchen' is installed as part of a gem, and
+# this file is here to facilitate running it.
+#
+
+require "pathname"
+ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../../Gemfile",
+  Pathname.new(__FILE__).realpath)
+
+bundle_binstub = File.expand_path("../bundle", __FILE__)
+
+if File.file?(bundle_binstub)
+  if File.read(bundle_binstub, 300) =~ /This file was generated by Bundler/
+    load(bundle_binstub)
+  else
+    abort("Your `bin/bundle` was not generated by Bundler, so this binstub cannot run.
+Replace `bin/bundle` by running `bundle binstubs bundler --force`, then run this command again.")
+  end
+end
+
+require "rubygems"
+require "bundler/setup"
+
+load Gem.bin_path("test-kitchen", "kitchen")

chrony/libtofs.jinja

@@ -83,17 +83,25 @@
     {%- for fs in fsl %}
       {%- for src_file in src_files %}
         {%- if fs %}
-          {%- set fs_dir = salt['config.get'](fs, fs) %}
+          {%- set fs_dirs = salt['config.get'](fs, fs) %}
         {%- else %}
-          {%- set fs_dir = salt['config.get'](tplroot ~ ':tofs:dirs:default', 'default') %}
+          {%- set fs_dirs = salt['config.get'](tplroot ~ ':tofs:dirs:default', 'default') %}
         {%- endif %}
-        {%- set url = '- salt://' ~ '/'.join([
-            path_prefix_inc_ext,
-            files_dir,
-            fs_dir,
-            src_file.lstrip('/')
-        ]) %}
+        {#- Force the `config.get` lookup result as a list where necessary #}
+        {#- since we need to also handle grains that are lists #}
+        {%- if fs_dirs is string %}
+          {%- set fs_dirs = [fs_dirs] %}
+        {%- endif %}
+        {%- for fs_dir in fs_dirs %}
+          {%- set url = [
+              '- salt:/',
+              path_prefix_inc_ext.strip('/'),
+              files_dir.strip('/'),
+              fs_dir.strip('/'),
+              src_file.strip('/'),
+          ] | select | join('/') %}
 {{ url | indent(indent_width, true) }}
+        {%- endfor %}
       {%- endfor %}
     {%- endfor %}
   {%- endfor %}

docs/CONTRIBUTING.rst

@@ -155,4 +155,5 @@ An example of that:
 
    BREAKING CHANGE: With the removal of all of the `.sls` files under
    `template package`, this formula no longer supports the installation of
-   packages.
+   packages.
+

docs/TOFS_pattern.rst

@@ -39,7 +39,7 @@ Using SaltStack is a simple and effective way to implement configuration managem
 
 To avoid this situation we can use the `pillar mechanism <http://docs.saltstack.com/en/latest/topics/pillar/>`_, which is designed to provide controlled access to data from the minions based on some selection rules. As pillar data could be easily integrated in the `Jinja <http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html>`_ templates, it is a good mechanism to store values to be used in the final rendering of state files and templates.
 
-There are a variety of approaches on the usage of pillar and templates as seen in the `saltstack-formulas <https://github.com/saltstack-formulas>`_' repositories. `Some <https://github.com/saltstack-formulas/nginx-formula/pull/18>`_ `developments <https://github.com/saltstack-formulas/php-formula/pull/14>`_ stress the initial purpose of pillar data into a storage for most of the possible variables for a determined system configuration. This, in my opinion, is shifting too much load from the original template files approach. Adding up some `non-trivial Jinja <https://github.com/spsoit/nginx-formula/blob/81de880fe0276dd9488ffa15bc78944c0fc2b919/nginx/ng/files/nginx.conf>`_ code as essential part of composing the state file definitely makes SaltStack state files (hence formulas) more difficult to read. The extreme of this approach is that we could end up with a new render mechanism, implemented in Jinja, storing everything needed in pillar data to compose configurations. Additionally, we are establishing a strong dependency with the Jinja renderer.
+There are a variety of approaches on the usage of pillar and templates as seen in the `saltstack-formulas <https://github.com/saltstack-formulas>`_' repositories. `Some <https://github.com/saltstack-formulas/nginx-formula/pull/18>`_ `developments <https://github.com/saltstack-formulas/php-formula/pull/14>`_ stress the initial purpose of pillar data into a storage for most of the possible variables for a determined system configuration. This, in my opinion, is shifting too much load from the original template files approach. Adding up some `non-trivial Jinja <https://github.com/saltstack-formulas/nginx-formula/blob/f74254c07e188bd448eaf1c5f9c802d78c4c005e/nginx/files/default/nginx.conf>`_ code as essential part of composing the state file definitely makes SaltStack state files (hence formulas) more difficult to read. The extreme of this approach is that we could end up with a new render mechanism, implemented in Jinja, storing everything needed in pillar data to compose configurations. Additionally, we are establishing a strong dependency with the Jinja renderer.
 
 In opposition to the *put the code in file_roots and the data in pillars* approach, there is the *pillar as a store for a set of key-values* approach. A full-blown configuration file abstracted in pillar and jinja is complicated to develop, understand and maintain. I think a better and simpler approach is to keep a configuration file templated using just a basic (non-extensive but extensible) set of pillar values.
 
@@ -325,6 +325,7 @@ We can simplify the ``conf.sls`` with the new ``files_switch`` macro to use in t
 
 
 * This uses ``config.get``, searching for ``ntp:tofs:source_files:Configure NTP`` to determine the list of template files to use.
+* If this returns a result, the default of ``['/etc/ntp.conf.jinja']`` will be appended to it.
 * If this does not yield any results, the default of ``['/etc/ntp.conf.jinja']`` will be used.
 
 In ``libtofs.jinja``, we define this new macro ``files_switch``.
@@ -426,18 +427,20 @@ The list of ``source_files`` can be given:
      tofs:
        source_files:
          Configure NTP:
-           - '/etc/ntp.conf.jinja'
            - '/etc/ntp.conf_alt.jinja'
 
 Resulting in:
 
 .. code-block:: sls
-   
+
          - source:
-           - salt://ntp/files/theminion/etc/ntp.conf.jinja
            - salt://ntp/files/theminion/etc/ntp.conf_alt.jinja
-           - salt://ntp/files/Debian/etc/ntp.conf.jinja
+           - salt://ntp/files/theminion/etc/ntp.conf.jinja
            - salt://ntp/files/Debian/etc/ntp.conf_alt.jinja
-           - salt://ntp/files/default/etc/ntp.conf.jinja
+           - salt://ntp/files/Debian/etc/ntp.conf.jinja
            - salt://ntp/files/default/etc/ntp.conf_alt.jinja
+           - salt://ntp/files/default/etc/ntp.conf.jinja
+
+Note: This does *not* override the default value.
+Rather, the value from the pillar/config is prepended to the default.
 

kitchen.yml

@@ -44,7 +44,7 @@ platforms:
         - sh bootstrap-salt.sh -XdPbfrq -x python3 git develop
       run_command: /usr/lib/systemd/systemd
 
-  ## SALT 2019.2
+  ## SALT `2019.2`
   - name: debian-9-2019-2-py3
     driver:
       image: netmanagers/salt-2019.2-py3:debian-9
@@ -62,7 +62,7 @@ platforms:
       image: netmanagers/salt-2019.2-py3:opensuse-leap-15
       run_command: /usr/lib/systemd/systemd
 
-  ## SALT 2018.3
+  ## SALT `2018.3`
   - name: debian-9-2018-3-py2
     driver:
       image: netmanagers/salt-2018.3-py2:debian-9
@@ -75,25 +75,18 @@ platforms:
   - name: fedora-29-2018-3-py2
     driver:
       image: netmanagers/salt-2018.3-py2:fedora-29
-  # TODO: Use this when fixed instead of `opensuse-leap-42`
-  # Ref: https://github.com/netmanagers/salt-image-builder/issues/2
-  # - name: opensuse-leap-15-2018-3-py2
-  #   driver:
-  #     image: netmanagers/salt-2018.3-py2:opensuse-leap-15
-  #     run_command: /usr/lib/systemd/systemd
   - name: opensuse-leap-42-2018-3-py2
     driver:
       image: netmanagers/salt-2018.3-py2:opensuse-leap-42
       run_command: /usr/lib/systemd/systemd
 
-  ## SALT 2017.7
+  ## SALT `2017.7`
   - name: debian-8-2017-7-py2
     driver:
       image: netmanagers/salt-2017.7-py2:debian-8
   - name: ubuntu-1604-2017-7-py2
     driver:
       image: netmanagers/salt-2017.7-py2:ubuntu-16.04
-  # TODO: Modify the formula to work for non-`systemd` platforms
   - name: centos-6-2017-7-py2
     driver:
       image: netmanagers/salt-2017.7-py2:centos-6
@@ -115,17 +108,6 @@ provisioner:
   salt_copy_filter:
     - .kitchen
     - .git
-  state_top:
-    base:
-      '*':
-        - chrony
-  pillars:
-    top.sls:
-      base:
-        '*':
-          - chrony
-  pillars_from_files:
-    chrony.sls: pillar.example
 
 verifier:
   # https://www.inspec.io/
@@ -134,8 +116,21 @@ verifier:
   # cli, documentation, html, progress, json, json-min, json-rspec, junit
   reporter:
     - cli
-  inspec_tests:
-    - path: test/integration/default
 
 suites:
   - name: default
+    provisioner:
+      state_top:
+        base:
+          '*':
+            - chrony
+      pillars:
+        top.sls:
+          base:
+            '*':
+              - chrony
+      pillars_from_files:
+        chrony.sls: pillar.example
+    verifier:
+      inspec_tests:
+        - path: test/integration/default

test/integration/default/README.md

@@ -0,0 +1,50 @@
+# InSpec Profile: `default`
+
+This shows the implementation of the `default` InSpec [profile](https://github.com/inspec/inspec/blob/master/docs/profiles.md).
+
+## Verify a profile
+
+InSpec ships with built-in features to verify a profile structure.
+
+```bash
+$ inspec check default
+Summary
+-------
+Location: default
+Profile: profile
+Controls: 4
+Timestamp: 2019-06-24T23:09:01+00:00
+Valid: true
+
+Errors
+------
+
+Warnings
+--------
+```
+
+## Execute a profile
+
+To run all **supported** controls on a local machine use `inspec exec /path/to/profile`.
+
+```bash
+$ inspec exec default
+..
+
+Finished in 0.0025 seconds (files took 0.12449 seconds to load)
+8 examples, 0 failures
+```
+
+## Execute a specific control from a profile
+
+To run one control from the profile use `inspec exec /path/to/profile --controls name`.
+
+```bash
+$ inspec exec default --controls package
+.
+
+Finished in 0.0025 seconds (files took 0.12449 seconds to load)
+1 examples, 0 failures
+```
+
+See an [example control here](https://github.com/inspec/inspec/blob/master/examples/profile/controls/example.rb).

test/integration/default/inspec.yml

@@ -1,11 +1,14 @@
-name: chrony
-title: Chrony Formula
-maintainer: Your Name
+name: default
+title: chrony formula
+maintainer: SaltStack Formulas
 license: Apache-2.0
 summary: Verify that the chrony formula is setup and configured correctly
 supports:
-  - os-name: debian
-  - os-name: ubuntu
-  - os-name: centos
-  - os-name: fedora
-  - os-name: opensuse
+  - platform-name: debian
+  - platform-name: ubuntu
+  - platform-name: centos
+  - platform-name: fedora
+  - platform-name: opensuse
+  - platform-name: suse
+  - platform-name: freebsd
+  - platform-name: amazon