Skip to content

Commit 61681c4

Browse files
noelmcloughlinnoelmcloughlin
authored
Merge pull request #35 from netmanagers/master
chore: follow template-formula guidelines
2 parents 82e4c46 + f5dbbf4 commit 61681c4

19 files changed

+641
-94
lines changed

‎.gitignore

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -47,6 +47,7 @@ coverage.xml
4747
.hypothesis/
4848
.kitchen
4949
.kitchen.local.yml
50+
kitchen.local.yml
5051

5152
# Translations
5253
*.mo
@@ -101,3 +102,12 @@ ENV/
101102

102103
# mypy
103104
.mypy_cache/
105+
106+
# Bundler
107+
Gemfile.lock
108+
109+
# copied `.md` files used for conversion to `.rst` using `m2r`
110+
docs/*.md
111+
112+
# Vim
113+
*.sw?

‎.kitchen.yml

Lines changed: 0 additions & 61 deletions
This file was deleted.

‎.travis.yml

Lines changed: 52 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,67 @@
1+
stages:
2+
- test
3+
- commitlint
4+
- name: release
5+
if: branch = master AND type != pull_request
6+
17
sudo: required
28
cache: bundler
39
language: ruby
410

511
services:
612
- docker
713

8-
before_install:
9-
- bundle install
10-
14+
# Make sure the instances listed below match up with
15+
# the `platforms` defined in `kitchen.yml`
16+
# NOTE: Please try to select up to six instances that add some meaningful
17+
# testing of the formula's behaviour. If possible, try to refrain from
18+
# the classical "chosing all the instances because I want to test on
19+
# another/all distro/s" trap: it will just add time to the testing (see
20+
# the discussion on #121). As an example, the set chosen below covers
21+
# the most used distros families, systemd and non-systemd and the latest
22+
# three supported Saltstack versions with python2 and 3."
23+
# As for `kitchen.yml`, that should still contain all of the platforms,
24+
# to allow for comprehensive local testing
25+
# Ref: https://github.com/saltstack-formulas/template-formula/issues/118
26+
# Ref: https://github.com/saltstack-formulas/template-formula/issues/121
1127
env:
1228
matrix:
1329
- INSTANCE: default-debian-9
14-
- INSTANCE: default-ubuntu-1804
1530
- INSTANCE: default-centos-7
16-
- INSTANCE: default-fedora-27
31+
- INSTANCE: default-fedora-29
1732

1833
script:
1934
- bundle exec kitchen verify ${INSTANCE}
2035

36+
jobs:
37+
include:
38+
# Define the commitlint stage
39+
- stage: commitlint
40+
language: node_js
41+
node_js: lts/*
42+
before_install: skip
43+
script:
44+
- npm install @commitlint/config-conventional -D
45+
- npm install @commitlint/travis-cli -D
46+
- commitlint-travis
47+
# Define the release stage that runs semantic-release
48+
- stage: release
49+
language: node_js
50+
node_js: lts/*
51+
before_install: skip
52+
script:
53+
# Update `AUTHORS.md`
54+
- export MAINTAINER_TOKEN=${GH_TOKEN}
55+
- go get github.com/myii/maintainer
56+
- maintainer contributor
57+
58+
# Install all dependencies required for `semantic-release`
59+
- npm install @semantic-release/changelog@3 -D
60+
- npm install @semantic-release/exec@3 -D
61+
- npm install @semantic-release/git@7 -D
62+
deploy:
63+
provider: script
64+
skip_cleanup: true
65+
script:
66+
# Run `semantic-release`
67+
- npx semantic-release@15

‎CHANGELOG.rst

Lines changed: 0 additions & 14 deletions
This file was deleted.

‎FORMULA

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
name: iptables
2+
os: Debian, Ubuntu, Raspbian, RedHat, Fedora, CentOS, Suse, openSUSE
3+
os_family: Debian, RedHat, Suse
4+
version: 0.2.0
5+
release: 1
6+
minimum_version: 2017.7
7+
summary: Iptables formula
8+
description: Formula to install and configure iptables in Linux
9+
top_level_dir: iptables

‎Gemfile

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,6 @@
1-
source 'https://rubygems.org'
1+
source "https://rubygems.org"
22

3-
gem 'test-kitchen', '>=1.20'
4-
gem 'kitchen-docker'
5-
gem 'kitchen-salt', '>=0.4.0'
6-
gem 'kitchen-inspec'
3+
gem 'kitchen-docker', '>= 2.9'
4+
gem 'kitchen-salt', '>= 0.6.0'
5+
gem 'kitchen-inspec', '>= 1.1'
76

‎LICENSE

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
Copyright (c) 2014 Salt Stack Formulas
2+
3+
Licensed under the Apache License, Version 2.0 (the "License");
4+
you may not use this file except in compliance with the License.
5+
You may obtain a copy of the License at
6+
7+
http://www.apache.org/licenses/LICENSE-2.0
8+
9+
Unless required by applicable law or agreed to in writing, software
10+
distributed under the License is distributed on an "AS IS" BASIS,
11+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12+
See the License for the specific language governing permissions and
13+
limitations under the License.

‎bin/kitchen

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
#!/usr/bin/env ruby
2+
# frozen_string_literal: true
3+
4+
#
5+
# This file was generated by Bundler.
6+
#
7+
# The application 'kitchen' is installed as part of a gem, and
8+
# this file is here to facilitate running it.
9+
#
10+
11+
require "pathname"
12+
ENV["BUNDLE_GEMFILE"] ||= File.expand_path("../../Gemfile",
13+
Pathname.new(__FILE__).realpath)
14+
15+
bundle_binstub = File.expand_path("../bundle", __FILE__)
16+
17+
if File.file?(bundle_binstub)
18+
if File.read(bundle_binstub, 300) =~ /This file was generated by Bundler/
19+
load(bundle_binstub)
20+
else
21+
abort("Your `bin/bundle` was not generated by Bundler, so this binstub cannot run.
22+
Replace `bin/bundle` by running `bundle binstubs bundler --force`, then run this command again.")
23+
end
24+
end
25+
26+
require "rubygems"
27+
require "bundler/setup"
28+
29+
load Gem.bin_path("test-kitchen", "kitchen")

‎commitlint.config.js

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
module.exports = {
2+
extends: ['@commitlint/config-conventional'],
3+
};

‎docs/CONTRIBUTING.rst

Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
1+
.. _contributing:
2+
3+
How to contribute
4+
=================
5+
6+
This document will eventually outline all aspects of guidance to make your contributing experience a fruitful and enjoyable one.
7+
What it already contains is information about *commit message formatting* and how that directly affects the numerous automated processes that are used for this repo.
8+
It also covers how to contribute to this *formula's documentation*.
9+
10+
.. contents:: **Table of Contents**
11+
12+
Overview
13+
--------
14+
15+
Submitting a pull request is more than just code!
16+
To achieve a quality product, the *tests* and *documentation* need to be updated as well.
17+
An excellent pull request will include these in the changes, wherever relevant.
18+
19+
Commit message formatting
20+
-------------------------
21+
22+
Since every type of change requires making Git commits,
23+
we will start by covering the importance of ensuring that all of your commit
24+
messages are in the correct format.
25+
26+
Automation of multiple processes
27+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
28+
29+
This formula uses `semantic-release <https://github.com/semantic-release/semantic-release>`_ for automating numerous processes such as bumping the version number appropriately, creating new tags/releases and updating the changelog.
30+
The entire process relies on the structure of commit messages to determine the version bump, which is then used for the rest of the automation.
31+
32+
Full details are available in the upstream docs regarding the `Angular Commit Message Conventions <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines>`_.
33+
The key factor is that the first line of the commit message must follow this format:
34+
35+
.. code-block::
36+
37+
type(scope): subject
38+
39+
40+
* E.g. ``docs(contributing): add commit message formatting instructions``.
41+
42+
Besides the version bump, the changelog and release notes are formatted accordingly.
43+
So based on the example above:
44+
45+
..
46+
47+
.. raw:: html
48+
49+
<h3>Documentation</h3>
50+
51+
* **contributing:** add commit message formatting instructions
52+
53+
54+
* The ``type`` translates into a ``Documentation`` sub-heading.
55+
* The ``(scope):`` will be shown in bold text without the brackets.
56+
* The ``subject`` follows the ``scope`` as standard text.
57+
58+
Linting commit messages in Travis CI
59+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
60+
61+
This formula uses `commitlint <https://github.com/conventional-changelog/commitlint>`_ for checking commit messages during CI testing.
62+
This ensures that they are in accordance with the ``semantic-release`` settings.
63+
64+
For more details about the default settings, refer back to the ``commitlint`` `reference rules <https://conventional-changelog.github.io/commitlint/#/reference-rules>`_.
65+
66+
Relationship between commit type and version bump
67+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
68+
69+
This formula applies some customisations to the defaults, as outlined in the table below,
70+
based upon the `type <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type>`_ of the commit:
71+
72+
.. list-table::
73+
:name: commit-type-vs-version-bump
74+
:header-rows: 1
75+
:stub-columns: 0
76+
:widths: 1,2,3,1,1
77+
78+
* - Type
79+
- Heading
80+
- Description
81+
- Bump (default)
82+
- Bump (custom)
83+
* - ``build``
84+
- Build System
85+
- Changes related to the build system
86+
- –
87+
-
88+
* - ``chore``
89+
- –
90+
- Changes to the build process or auxiliary tools and libraries such as
91+
documentation generation
92+
- –
93+
-
94+
* - ``ci``
95+
- Continuous Integration
96+
- Changes to the continuous integration configuration
97+
- –
98+
-
99+
* - ``docs``
100+
- Documentation
101+
- Documentation only changes
102+
- –
103+
- 0.0.1
104+
* - ``feat``
105+
- Features
106+
- A new feature
107+
- 0.1.0
108+
-
109+
* - ``fix``
110+
- Bug Fixes
111+
- A bug fix
112+
- 0.0.1
113+
-
114+
* - ``perf``
115+
- Performance Improvements
116+
- A code change that improves performance
117+
- 0.0.1
118+
-
119+
* - ``refactor``
120+
- Code Refactoring
121+
- A code change that neither fixes a bug nor adds a feature
122+
- –
123+
- 0.0.1
124+
* - ``revert``
125+
- Reverts
126+
- A commit used to revert a previous commit
127+
- –
128+
- 0.0.1
129+
* - ``style``
130+
- Styles
131+
- Changes that do not affect the meaning of the code (white-space,
132+
formatting, missing semi-colons, etc.)
133+
- –
134+
- 0.0.1
135+
* - ``test``
136+
- Tests
137+
- Adding missing or correcting existing tests
138+
- –
139+
- 0.0.1
140+
141+
Use ``BREAKING CHANGE`` to trigger a ``major`` version change
142+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
143+
144+
Adding ``BREAKING CHANGE`` to the footer of the extended description of the commit message will **always** trigger a ``major`` version change, no matter which type has been used.
145+
This will be appended to the changelog and release notes as well.
146+
To preserve good formatting of these notes, the following format is prescribed:
147+
148+
* ``BREAKING CHANGE: <explanation in paragraph format>.``
149+
150+
An example of that:
151+
152+
.. code-block:: git
153+
154+
...
155+
156+
BREAKING CHANGE: With the removal of all of the `.sls` files under
157+
`template package`, this formula no longer supports the installation of
158+
packages.

0 commit comments

Comments
 (0)