.github/workflows | ||
bin | ||
docs | ||
TEMPLATE | ||
test | ||
.gitignore | ||
.gitlab-ci.yml | ||
.pre-commit-config.yaml | ||
.rstcheck.cfg | ||
.rubocop.yml | ||
.salt-lint | ||
.travis.yml | ||
.yamllint | ||
AUTHORS.md | ||
CHANGELOG.md | ||
CODEOWNERS | ||
commitlint.config.js | ||
FORMULA | ||
Gemfile | ||
Gemfile.lock | ||
kitchen.yml | ||
LICENSE | ||
pillar.example | ||
pre-commit_semantic-release.sh | ||
release-rules.js | ||
release.config.js |
TEMPLATE-formula
A SaltStack formula that is empty. It has dummy content to help with a quick start on a new formula and it serves as a style guide.
Table of Contents
General notes
See the full SaltStack Formulas installation and usage instructions.
If you are interested in writing or contributing to formulas, please pay attention to the Writing Formula Section.
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.
See Formula Versioning Section for more details.
If you need (non-default) configuration, please refer to:
- how to configure the formula with map.jinja
- the
pillar.example
file - the Special notes section
Contributing to this repo
Commit messages
Commit message formatting is significant!!
Please see How to contribute for more details.
pre-commit
pre-commit is configured for
this formula, which you may optionally use to ease the steps involved in
submitting your changes. First install the pre-commit
package manager using the appropriate method, then run
bin/install-hooks
and now pre-commit
will run
automatically on each git commit
. :
$ bin/install-hooks
pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg
Special notes
Using this template
The easiest way to use this template formula as a base for a new
formula is to use GitHub's Use this template button to
create a new repository. For consistency with the rest of the formula
ecosystem, name your formula repository following the pattern
<formula theme>-formula
, where
<formula theme>
consists of lower-case alphabetic
characters, numbers, '-' or '_'.
In the rest of this example we'll use example
as the
<formula theme>
.
Follow these steps to complete the conversion from
template-formula
to example-formula
. :
$ git clone git@github.com:YOUR-USERNAME/example-formula.git
$ cd example-formula/
$ bin/convert-formula.sh example
$ git push --force
Alternatively, it's possible to clone template-formula
into a new repository and perform the conversion there. For example:
$ git clone https://github.com/saltstack-formulas/template-formula example-formula
$ cd example-formula/
$ bin/convert-formula.sh example
To take advantage of semantic-release for automated changelog generation and release tagging, you will need a GitHub Personal Access Token with at least the public_repo scope.
In the Travis repository settings for your new repository, create an
environment
variable named GH_TOKEN
with the personal access token
as value, restricted to the master
branch for security.
Note that this repository uses a CODEOWNERS
file to assign ownership to various parts of the formula. The conversion
process removes overall ownership, but you should consider assigning
ownership to yourself or your organisation when contributing your new
formula to the saltstack-formulas
organisation.
Available states
TEMPLATE
Meta-state (This is a state that includes other states).
This installs the TEMPLATE package, manages the TEMPLATE configuration file and then starts the associated TEMPLATE service.
TEMPLATE.package
This state will install the TEMPLATE package only.
TEMPLATE.config
This state will configure the TEMPLATE service and has a dependency
on TEMPLATE.install
via include list.
TEMPLATE.service
This state will start the TEMPLATE service and has a dependency on
TEMPLATE.config
via include list.
TEMPLATE.clean
Meta-state (This is a state that includes other states).
this state will undo everything performed in the
TEMPLATE
meta-state in reverse order, i.e. stops the
service, removes the configuration file and then uninstalls the
package.
TEMPLATE.service.clean
This state will stop the TEMPLATE service and disable it at boot time.
TEMPLATE.config.clean
This state will remove the configuration of the TEMPLATE service and
has a dependency on TEMPLATE.service.clean
via include
list.
TEMPLATE.package.clean
This state will remove the TEMPLATE package and has a depency on
TEMPLATE.config.clean
via include list.
TEMPLATE.subcomponent
Meta-state (This is a state that includes other states).
This state installs a subcomponent configuration file before configuring and starting the TEMPLATE service.
TEMPLATE.subcomponent.config
This state will configure the TEMPLATE subcomponent and has a
dependency on TEMPLATE.config
via include list.
TEMPLATE.subcomponent.config.clean
This state will remove the configuration of the TEMPLATE subcomponent
and reload the TEMPLATE service by a dependency on
TEMPLATE.service.running
via include list and
watch_in
requisite.
Testing
Linux testing is done with kitchen-salt
.
Requirements
- Ruby
- Docker
$ 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 TEMPLATE
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.