mirror of
https://github.com/saltstack-formulas/sysctl-formula.git
synced 2026-07-14 19:36:11 +02:00
feat(semantic-release): add semantic-release
This commit is contained in:
Nicolas Rodriguez
@@ -0,0 +1,159 @@
|
||||
.. _contributing:
|
||||
|
||||
How to contribute
|
||||
=================
|
||||
|
||||
This document will eventually outline all aspects of guidance to make your contributing experience a fruitful and enjoyable one.
|
||||
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.
|
||||
It also covers how to contribute to this *formula's documentation*.
|
||||
|
||||
.. contents:: **Table of Contents**
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Submitting a pull request is more than just code!
|
||||
To achieve a quality product, the *tests* and *documentation* need to be updated as well.
|
||||
An excellent pull request will include these in the changes, wherever relevant.
|
||||
|
||||
Commit message formatting
|
||||
-------------------------
|
||||
|
||||
Since every type of change requires making Git commits,
|
||||
we will start by covering the importance of ensuring that all of your commit
|
||||
messages are in the correct format.
|
||||
|
||||
Automation of multiple processes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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>`_.
|
||||
The key factor is that the first line of the commit message must follow this format:
|
||||
|
||||
.. code-block::
|
||||
|
||||
type(scope): subject
|
||||
|
||||
|
||||
* E.g. ``docs(contributing): add commit message formatting instructions``.
|
||||
|
||||
Besides the version bump, the changelog and release notes are formatted accordingly.
|
||||
So based on the example above:
|
||||
|
||||
..
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<h3>Documentation</h3>
|
||||
|
||||
* **contributing:** add commit message formatting instructions
|
||||
|
||||
|
||||
* The ``type`` translates into a ``Documentation`` sub-heading.
|
||||
* The ``(scope):`` will be shown in bold text without the brackets.
|
||||
* The ``subject`` follows the ``scope`` as standard text.
|
||||
|
||||
Linting commit messages in Travis CI
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This formula uses `commitlint <https://github.com/conventional-changelog/commitlint>`_ for checking commit messages during CI testing.
|
||||
This ensures that they are in accordance with the ``semantic-release`` settings.
|
||||
|
||||
For more details about the default settings, refer back to the ``commitlint`` `reference rules <https://conventional-changelog.github.io/commitlint/#/reference-rules>`_.
|
||||
|
||||
Relationship between commit type and version bump
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This formula applies some customisations to the defaults, as outlined in the table below,
|
||||
based upon the `type <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type>`_ of the commit:
|
||||
|
||||
.. list-table::
|
||||
:name: commit-type-vs-version-bump
|
||||
:header-rows: 1
|
||||
:stub-columns: 0
|
||||
:widths: 1,2,3,1,1
|
||||
|
||||
* - Type
|
||||
- Heading
|
||||
- Description
|
||||
- Bump (default)
|
||||
- Bump (custom)
|
||||
* - ``build``
|
||||
- Build System
|
||||
- Changes related to the build system
|
||||
- –
|
||||
-
|
||||
* - ``chore``
|
||||
- –
|
||||
- Changes to the build process or auxiliary tools and libraries such as
|
||||
documentation generation
|
||||
- –
|
||||
-
|
||||
* - ``ci``
|
||||
- Continuous Integration
|
||||
- Changes to the continuous integration configuration
|
||||
- –
|
||||
-
|
||||
* - ``docs``
|
||||
- Documentation
|
||||
- Documentation only changes
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``feat``
|
||||
- Features
|
||||
- A new feature
|
||||
- 0.1.0
|
||||
-
|
||||
* - ``fix``
|
||||
- Bug Fixes
|
||||
- A bug fix
|
||||
- 0.0.1
|
||||
-
|
||||
* - ``perf``
|
||||
- Performance Improvements
|
||||
- A code change that improves performance
|
||||
- 0.0.1
|
||||
-
|
||||
* - ``refactor``
|
||||
- Code Refactoring
|
||||
- A code change that neither fixes a bug nor adds a feature
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``revert``
|
||||
- Reverts
|
||||
- A commit used to revert a previous commit
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``style``
|
||||
- Styles
|
||||
- Changes that do not affect the meaning of the code (white-space,
|
||||
formatting, missing semi-colons, etc.)
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``test``
|
||||
- Tests
|
||||
- Adding missing or correcting existing tests
|
||||
- –
|
||||
- 0.0.1
|
||||
|
||||
Use ``BREAKING CHANGE`` to trigger a ``major`` version change
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
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.
|
||||
This will be appended to the changelog and release notes as well.
|
||||
To preserve good formatting of these notes, the following format is prescribed:
|
||||
|
||||
* ``BREAKING CHANGE: <explanation in paragraph format>.``
|
||||
|
||||
An example of that:
|
||||
|
||||
.. code-block:: git
|
||||
|
||||
...
|
||||
|
||||
BREAKING CHANGE: With the removal of all of the `.sls` files under
|
||||
`template package`, this formula no longer supports the installation of
|
||||
packages.
|
||||
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
.. _readme:
|
||||
|
||||
sysctl-formula
|
||||
==============
|
||||
|
||||
|img_travis| |img_sr|
|
||||
|
||||
.. |img_travis| image:: https://travis-ci.com/saltstack-formulas/sysctl-formula.svg?branch=master
|
||||
:alt: Travis CI Build Status
|
||||
:scale: 100%
|
||||
:target: https://travis-ci.com/saltstack-formulas/sysctl-formula
|
||||
.. |img_sr| image:: https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg
|
||||
:alt: Semantic Release
|
||||
:scale: 100%
|
||||
:target: https://github.com/semantic-release/semantic-release
|
||||
|
||||
Formula to set up and configure sysctl.
|
||||
|
||||
.. contents:: **Table of Contents**
|
||||
|
||||
General notes
|
||||
-------------
|
||||
|
||||
See the full `SaltStack Formulas installation and usage instructions
|
||||
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.
|
||||
|
||||
If you are interested in writing or contributing to formulas, please pay attention to the `Writing Formula Section
|
||||
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#writing-formulas>`_.
|
||||
|
||||
If you want to use this formula, please pay attention to the ``FORMULA`` file and/or ``git tag``,
|
||||
which contains the currently released version. This formula is versioned according to `Semantic Versioning <http://semver.org/>`_.
|
||||
|
||||
See `Formula Versioning Section <https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#versioning>`_ for more details.
|
||||
|
||||
Contributing to this repo
|
||||
-------------------------
|
||||
|
||||
**Commit message formatting is significant!!**
|
||||
|
||||
Please see :ref:`How to contribute <CONTRIBUTING>` for more details.
|
||||
|
||||
Available states
|
||||
----------------
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
``sysctl``
|
||||
^^^^^^^^^^
|
||||
Installs and configures the sysctl package.
|
||||
|
||||
``sysctl.package``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
Installs the sysctl package.
|
||||
|
||||
``sysctl.param``
|
||||
^^^^^^^^^^^^^^^
|
||||
This state manages the file ``sysctl.conf`` under ``/etc/sysctl`` (template found in "sysctl/files"). The configuration is populated by values in "sysctl/map.jinja" based on the package's default values (and RedHat, Debian, Suse and Arch family distribution specific values), which can then be overridden by values of the same name in pillar.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Linux testing is done with ``kitchen-salt``.
|
||||
|
||||
Requirements
|
||||
^^^^^^^^^^^^
|
||||
|
||||
* Ruby
|
||||
* Docker
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ gem install bundler
|
||||
$ bundle install
|
||||
$ bin/kitchen test [platform]
|
||||
|
||||
Where ``[platform]`` is the platform name defined in ``kitchen.yml``,
|
||||
e.g. ``debian-9-2019-2-py3``.
|
||||
|
||||
``bin/kitchen converge``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Creates the docker instance and runs the ``sysctl`` main state, ready for testing.
|
||||
|
||||
``bin/kitchen verify``
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Runs the ``inspec`` tests on the actual instance.
|
||||
|
||||
``bin/kitchen destroy``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Removes the docker instance.
|
||||
|
||||
``bin/kitchen test``
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Runs all of the stages above in one go: i.e. ``destroy`` + ``converge`` + ``verify`` + ``destroy``.
|
||||
|
||||
``bin/kitchen login``
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Gives you SSH access to the instance for manual testing.
|
||||
Reference in New Issue
Block a user