64 lines
2.5 KiB
Raw Permalink Normal View History

2016-09-28 18:23:50 +02:00
# Ansible-roles
A repository for Ansible roles used by Evolix on Debian GNU/Linux 9 (stretch) servers.
Few roles are also be compatible with Debian GNU/Linux 8 (jessie) servers.
2016-12-21 16:11:09 +01:00
It contains only roles, everything else is available at
2019-03-21 15:31:22 +01:00
2016-12-22 09:46:37 +01:00
## Branches
2016-12-22 09:46:37 +01:00
The **stable** branch contains roles that we consider ready for production.
The **unstable** branch contains not sufficiently tested roles (or evolutions on existing roles) that we don't consider ready for production yet.
Many feature branches may exist in the repository. They represent "work in progress". They may be used, for testing purposes.
## Install and usage
First, check-out the repository :
$ cd ~/GIT/
2019-03-21 15:31:22 +01:00
$ git clone
Then, add its path to your ansible load path :
$ vim ~/.ansible.cfg
roles_path = $HOME/GIT/ansible-roles
Then, include roles in your playbooks :
- hosts: all
gather_facts: yes
become: yes
- etc-git
- evolinux-base
## Contributing
Contributions are welcome, especially bug fixes and "ansible good practices". They will be merged in if they are consistent with our conventions and use cases. They might be rejected if they introduce complexity, cover features we don't need or don't fit "style".
Before starting anything of importance, we suggest contacting us to discuss what you'd like to add or change.
2019-03-21 15:31:22 +01:00
Our conventions are available in the "ansible-public": repository, in the file.
2021-02-04 11:13:05 +01:00
All modifications should be documented in the CHANGELOG file, to help review releases. We encourage atomic commits, on a single role, and with the CHANGELOG in the same commit.
## Workflow
The ideal and most typical workflow is to create a branch, based on the "unstable" branch. The branch should have a descriptive name (a ticket/issue number is great). The branch can be treated as a pull-request or merge-request. It should be propery tested and reviewed before merging into "unstable".
Changes that don't introduce significant changes — or that must go faster that the typical workflow — can be commited directly into "unstable".
Hotfixes, can be prepared on a new branch, based on "stable" or "unstable" (to be decided by the author). When ready, it can be merged back to "stable" for immediate deployment and to "unstable" for proper backporting.
Other workflow are not forbidden, but should be discussed in advance.