jonaspammer.bootstrap

Voici la traduction en français :

// Ce fichier est généré par .github/workflows/gh-pages.yml - toutes les modifications locales seront perdues à terme !
= ansible-role-bootstrap
Jonas Pammer <[email protected]>;
:toc: gauche
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge

https://galaxy.ansible.com/jonaspammer/bootstrap[image:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.bootstrap-brightgreen[Version sur Galaxy]]
// Badges d'état très pertinents
https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/ci.yml/badge.svg[Testing CI]]

Un rôle Ansible pour préparer un système Linux à être géré par Ansible.

Ce rôle utilise le https://docs.ansible.com/ansible-core/2.16/collections/ansible/builtin/raw_module.html[`ansible.builtin.raw` module]
en combinaison avec un "système de détermination de système d'exploitation" implémenté par mes soins
pour installer l'ensemble minimum de packages requis (`python` et `sudo`)
afin de permettre à Ansible de gérer un système.

Ce rôle garantit également un cache de packages à jour pour la plupart des systèmes.

Dans la plupart des cas, vous voudrez utiliser ce rôle en combinaison avec mon
https://github.com/JonasPammer/ansible-role-core_dependencies[`core_dependencies`-role].

[NOTE]
.DISCLAIMER
=====
Ce rôle est un fork de https://github.com/robertdebock/ansible-role-bootstrap/releases/tag/5.2.12[robertdebock/ansible-role-bootstrap v5.2.12 (27 janvier 2022)]
(Licence Apache 2.0, Copyright Robert de Bock ([email protected]))
avec divers changements/corrections. +
Extrait des changements de https://github.com/JonasPammer/ansible-role-bootstrap/releases[/releases] ci-dessous (avec les problèmes accompagnants dans le dépôt de robertdebock) :

* Le rôle lui-même devrait pré-chauffer le cache du gestionnaire de paquets :
  https://github.com/robertdebock/ansible-role-bootstrap/pull/57[robertdebock/ansible-role-bootstrap#57]
  ( corrigé dans
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/43[JonasPammer#43];
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/50[JonasPammer#50]
  )
* changer la valeur par défaut de become à `false`, ajouter la possibilité de définir `become_user` séparément de `ansible_user` :
  https://github.com/robertdebock/ansible-role-bootstrap/issues/63[robertdebock/ansible-role-bootstrap#63]
  ( corrigé dans
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/61[JonasPammer#61]
  )
* changer la valeur par défaut de `bootstrap_become_user` à root
* utiliser `bootstrap_become_user` dans les étapes des modules ansible aussi
* rendre le rôle compatible avec podman en spécifiant `/bin/sh`
  https://github.com/robertdebock/ansible-role-bootstrap/pull/66[robertdebock/ansible-role-bootstrap#66]
  ( corrigé dans
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/62[JonasPammer#62]
  )
=====

toc::[]

[[meta]]
== 🔎 Métadonnées
Vous pouvez trouver ci-dessous des informations sur…

* la version requise d'Ansible pour le rôle
* les plates-formes supportées par le rôle
* les https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[dépendances du rôle]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: bootstrap
  description: Un rôle Ansible pour préparer un système Linux à être géré par Ansible. Basé sur le rôle de robertdebock.

  author: jonaspammer
  license: "MIT"

  min_ansible_version: "2.9"
  platforms:
    # note : le texte après "testé activement : " représente le nom de l'image docker
    - name: EL # (Enterprise Linux)
      versions:
        - "9" # testé activement : rockylinux9
    - name: Fedora
      versions:
        - "38" # testé activement : fedora38
        - "39" # testé activement : fedora39
    - name: Debian
      versions:
        - bullseye # testé activement : debian11
        - bookworm # testé activement : debian12
    - name: Ubuntu
      versions:
        - focal # testé activement : ubuntu2004
        - jammy # testé activement : ubuntu2204

  galaxy_tags:
    - bootstrap
    - python
    - sudo

dependencies: []
----

[[requirements]]
== 📌 Exigences
// Toute condition préalable qui pourrait ne pas être couverte par ce rôle ou Ansible lui-même doit être mentionnée ici.
L'utilisateur Ansible doit être capable de `devenir`.

[[variables]]
== 📜 Variables du rôle
// Une description des variables définissables pour ce rôle doit aller ici
// et toutes les variables pouvant/doivent être définies via des paramètres pour le rôle.
// Toute variable lue à partir d'autres rôles et/ou de la portée globale (c'est-à-dire hostvars, vars de groupe, etc.)
// doit également être mentionnée ici.

[source,yaml]
----
bootstrap_user: root
----
https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#term-ansible_user[Nom d'utilisateur]
Utilisé pour se connecter à la machine pour les tâches principales `raw` de _collecte de faits simples_ / _installation_.

[source,yaml]
----
bootstrap_become: false
bootstrap_become_user: root
----
Les variables `become` et `become_user` passées à la plupart des tâches réelles.

La valeur par défaut de `bootstrap_become` a été définie sur `false`
en raison de l'hypothèse que `sudo` n'est pas disponible
avant le bootstrap.

[source,yaml]
----
bootstrap_wait_for_host: false
----
Indique s'il faut attendre que l'hôte soit disponible sur `ansible_port` (22).

[source,yaml]
----
bootstrap_timeout: 3
----
Nombre maximal de secondes d'attente pour que le système distant soit accessible/utilisable avant d'échouer.


[[public_vars]]
== 📜 Faits/Variables définis par ce rôle

Chaque variable répertoriée dans cette section
est définie dynamiquement lors de l'exécution de ce rôle (et ne peut être écrasée qu'à l'aide de `ansible.builtin.set_facts`) _et_
est destinée à être utilisée non seulement en interne.


[[tags]]
== 🏷️ Étiquettes

// Consultez https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// pour un excellent exemple de regroupement des tâches à l'aide d'étiquettes.

Les tâches sont étiquetées avec les
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[étiquettes]:

[cols="1,1"]
|===
|Tag | But

2+| Ce rôle n'a pas encore d'étiquettes officiellement documentées.

// | download-xyz
// |
// | install-prerequisites
// |
// | install
// |
// | create-xyz
// |
|===

Vous pouvez utiliser Ansible pour ignorer des tâches, ou exécuter uniquement certaines tâches en utilisant ces étiquettes. Par défaut, toutes les tâches s'exécutent lorsque aucune étiquette n'est spécifiée.

[[dependencies]]
== 👫 Dépendances
// Une liste d'autres rôles doit aller ici,
// plus tout détail concernant les paramètres qui pourraient devoir être définis pour d'autres rôles,
// ou des variables utilisées à partir d'autres rôles.


[[example_playbooks]]
== 📚 Exemples d'utilisation des playbooks
// Inclure des exemples de la façon d'utiliser ce rôle dans un playbook pour des scénarios courants est toujours utile pour les utilisateurs :

[IMPORTANT]
====
Vous devez désactiver la propriété `gather_facts` du play dans lequel ce rôle est utilisé.
Si ce rôle s'achève avec succès, il appellera lui-même https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html[
le module de configuration d'Ansible] (effet équivalent à ce que donnerait `gather_facts: true`).

Aucune tâche ne doit venir avant ce rôle.
====

.Minimum Viable Play
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrap des machines linux à gérer avec Ansible.
  become: false
  gather_facts: false

  roles:
    - role: jonaspammer.bootstrap
-----
====

.Changer l'utilisateur bootstrap (par exemple, lorsque root n'est pas une option)
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrap des machines linux à gérer avec Ansible.
  become: false
  gather_facts: false

  vars:
    bootstrap_user: "{{ ansible_user }}"

  roles:
    - role: jonaspammer.bootstrap
-----
====


. Utiliser become à true (par exemple, lorsque vous savez que vous avez au moins un sudo utilisable)
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrap des machines linux à gérer avec Ansible.
  become: true
  gather_facts: false

  vars:
    bootstrap_user: "{{ ansible_user }}"
    bootstrap_become: true

  roles:
    - role: jonaspammer.bootstrap
-----
====


[[tested-distributions]]
== 🧪 Distributions testées

Un rôle peut fonctionner sur différentes *distributions*, comme Red Hat Enterprise Linux (RHEL),
même s'il n'y a pas de test pour cette distribution exacte.

// bonne référence à suivre -- projet le plus étoilé et épinglé de geerlingguy :
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Famille OS | Distribution | Date de sortie de la distribution | Date de fin de vie de la distribution | Image Docker accompagnante

// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 sous un nouveau nom])
| 2021-06
| 2029-05
| https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky
| Rocky Linux 9
| 2022-07
| 2032-05
| https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://endoflife.date/fedora (13 mois)
| RedHat
| Fedora 39
| 2023-11
| 2024-12
| https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-fedora39-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://ubuntu.com/about/release-cycle
| Debian
| Ubuntu 20.04 LTS
| 2021-04
| 2025-04
| https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Ubuntu 22.04 LTS
| 2022-04
| 2027-04
| https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://wiki.debian.org/DebianReleases
// https://wiki.debian.org/LTS
| Debian
| Debian 11
| 2021-08
| 2024-06 (2026-06 LTS)
| https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian
| Debian 12
| 2023-06
| 2026-06 (2028-06 LTS)
| https://github.com/geerlingguy/docker-debian12-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]]
|===


[[tested-ansible-versions]]
== 🧪 Versions d'Ansible testées

Les versions d'Ansible testées essaient de rester équivalentes à la
https://github.com/ansible-collections/community.general#tested-with-ansible[
modèle de prise en charge de la collection `community.general` d'Ansible].
Au moment de la rédaction de ce document, il s'agit de :

* 2.13 (Ansible 6)
* 2.14 (Ansible 7)
* 2.15 (Ansible 8)
* 2.16 (Ansible 9)


[[development]]
== 📝 Développement
// Badges concernant les conventions de ce projet
https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Conventional Commits]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-bootstrap/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-bootstrap/master.svg[Statut pre-commit]]
// image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, link=https://github.com/pre-commit/pre-commit]

[[development-system-dependencies]]
=== 📌 Dépendances de la machine de développement

* Python 3.10 ou supérieur
* Docker

[[development-dependencies]]
=== 📌 Dépendances de développement
Les dépendances de développement sont définies dans un
https://pip.pypa.io/en/stable/user_guide/#requirements-files[fichier de requêtes pip]
appelé `requirements-dev.txt`.
Les instructions d'installation d'exemple pour Linux sont montrées ci-dessous :

----
# "optionnel" : créez un environnement virtuel python et activez-le pour la session actuelle du shell
$ python3 -m venv venv
$ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt
----

[[development-guidelines]]
=== ℹ️ Consignes de développement de rôle Ansible

Veuillez consulter mes https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Consignes de développement de rôle Ansible].

Si vous êtes intéressé, j'ai également écrit quelques
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Bonnes pratiques de développement de rôles Ansible].

[[versioning]]
=== 🔢 Versionnage

Les versions sont définies à l'aide des https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tags],
qui à leur tour sont https://galaxy.ansible.com/docs/contributing/version.html[reconnus et utilisés] par Ansible Galaxy.

*Les versions ne doivent pas commencer par `v`.*

Lorsqu'un nouveau tag est poussé, https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml[
un workflow CI GitHub]
(image:https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml/badge.svg[CI de Release])
s'occupe d'importer le rôle dans mon compte Ansible Galaxy.

[[testing]]
=== 🧪 Tests
Des tests automatiques sont exécutés à chaque contribution en utilisant les workflows GitHub.

Les tests concernent principalement l'exécution de https://molecule.readthedocs.io/en/latest/[Molecule]
sur un <<tested-distributions,ensemble variable de distributions linux>>
et l'utilisation de <<tested-ansible-versions,diverses versions d'Ansible>>.

Le test de Molecule inclut également une étape qui analyse tous les playbooks Ansible en utilisant
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
pour vérifier les bonnes pratiques et le comportement pouvant être amélioré.

Pour exécuter les tests, il suffit d'exécuter `tox` dans la ligne de commande.
Vous pouvez passer une variable d'environnement optionnelle pour définir la distribution du
conteneur Docker qui sera créé par Molecule :

----
$ MOLECULE_DISTRO=ubuntu2204 tox
----

Pour une liste des valeurs possibles transmises à `MOLECULE_DISTRO`,
voyez la matrice définie dans link:.github/workflows/ci.yml[].

==== 🐛 Débogage d'un conteneur Molecule

1. Exécutez vos tests Molecule avec l'option `MOLECULE_DESTROY=never`, par exemple :
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TASK [ansible-role-pip : (réducteur).] pass:[************************]
  échec: [instance-py3-ansible-9] => changed=false
...
 pass:[___________________________________ résumé ____________________________________]
  pre-commit: commandes réussies
ERROR:   py3-ansible-9: commandes échouées
----

2. Trouvez le nom du conteneur docker provisionné par Molecule :
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   il y a 8 minutes   En cours depuis 8 minutes                                                                                                    instance-py3-ansible-9
----

3. Entrez dans un shell bash du conteneur, et effectuez votre débogage :
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*

root@instance-py3-ansible-2:/#
----
+
[TIP]
====
Si l'échec que vous essayez de déboguer fait partie de votre étape `verify.yml` et non de la `converge.yml` réelle,
vous voudrez peut-être savoir que la sortie des modules d'Ansible (`vars`), des hôtes (`hostvars`) et
des variables d'environnement ont été stockées dans des fichiers sur le provisionneur et dans la machine docker sous :

* `/var/tmp/vars.yml` (contient les variables hôtes sous la clé `hostvars`)
* `/var/tmp/environment.yml`

`grep`, `cat` ou transférez-les comme vous le souhaitez !
====
+
[TIP]
=====
Vous voudrez également savoir que les fichiers mentionnés dans l'avertissement ci-dessus
sont attachés aux *Artifacts CI de GitHub* d'un run de workflow donné. +
Cela permet de vérifier les différences entre les exécutions
et donc d'aider à déboguer ce qui a causé le "bit-rot" ou l'échec en général.

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]
=====

4. Après avoir terminé votre débogage, quittez-le et détruisez le conteneur :
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*

$ *docker stop #30e9b8d59cdf#*

$ *docker container rm #30e9b8d59cdf#*
_ou_
$ *docker container prune*
----

==== 🐛 Débogage des versions de packages installés localement

Bien qu'une fonctionnalité standard dans tox 3, cela https://github.com/tox-dev/tox/pull/2794[n'est maintenant possible que]
lorsque tox reconnaît la présence d'une variable CI.
Par exemple :

----
$ CI=true tox
----


[[development-container-extra]]
=== 🧃 ASTUCE : Environnement de développement idéal conteneurisé

Ce projet offre une définition pour un "environnement de développement conteneurisé en un clic".

Ce conteneur permet même de faire fonctionner des conteneurs docker à l'intérieur (Docker-In-Docker, dind),
permettant l'exécution de Molecule.

Pour l'utiliser :

1. Assurez-vous de remplir les link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   exigences système des Conteneurs de Développement Visual Studio Code],
   en suivant éventuellement la section __Installation__ de la page liée. +
   Cela inclut : Installation de Docker, installation de Visual Studio Code lui-même et installation de l'extension nécessaire.
2. Clonez le projet sur votre machine
3. Ouvrez le dossier du dépôt dans Visual Studio Code (_Fichier - Ouvrir un dossier…_).
4. Si vous recevez une invite au coin inférieur droit vous informant de la présence de la définition du devcontainer,
vous pouvez appuyer sur le bouton associé pour y entrer.
*Sinon,* vous pouvez également exécuter la Commande Visual Studio `Remote-Containers: Open Folder in Container` vous-même (_Affichage - Palette de commandes_ -> _tapez dans la commande mentionnée_).

[TIP]
====
Je recommande d'utiliser `Remote-Containers: Rebuild Without Cache and Reopen in Container`
de temps en temps car la fonctionnalité devcontainer a parfois des problèmes pour reconnaître
les modifications apportées à sa définition.
====

[NOTE]
=====
Vous devrez peut-être configurer votre système hôte pour permettre au conteneur d'utiliser vos clés SSH/GPG.

La procédure est décrite https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
dans la documentation officielle des devcontainers sous "Partage des identifiants Git avec votre conteneur"].
=====


[[cookiecutter]]
=== 🍪 CookieCutter

Ce projet doit être synchronisé avec
https://github.com/JonasPammer/cookiecutter-ansible-role[le CookieCutter à partir duquel il a été initialement modélisé]
en utilisant https://github.com/cruft/cruft[cruft] (si possible) ou une modification manuelle (si nécessaire)
dans la meilleure mesure possible.

. Exemple officiel d'utilisation de `cruft update`
____
image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Exemple officiel d'utilisation de `cruft update`]
____

==== 🕗 Journal des modifications
Lorsqu'un nouveau tag est poussé, une Release GitHub appropriée sera créée
par le mainteneur du dépôt pour fournir un journal des modifications humain approprié avec un titre et une description.


[[pre-commit]]
=== ℹ️ Conventions générales de linting et de style
Les conventions générales de linting et de style sont
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automatiquement* respectées]
par divers https://pre-commit.com/[hooks `pre-commit`], au moins dans une certaine mesure.

L'exécution automatique de pre-commit est effectuée à chaque contribution en utilisant
https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Les demandes de tirage sont même automatiquement corrigées par le même outil,
au moins par des hooks qui modifient automatiquement des fichiers.

[NOTE]
====
Ne pas confondre :
Bien que certains hooks de pre-commit puissent être en mesure de vous avertir des défauts analysés par script dans la syntaxe ou même dans le code dans une certaine mesure (pour laquelle les hooks de pre-commit font *partie de* la suite de tests),
pre-commit lui-même n'exécute pas de vraies suites de tests.
Pour des informations sur les tests, voir <<testing>>.
====

[TIP]
====
[[note_pre-commit-ci]]
Néanmoins, je vous recommande d'intégrer pre-commit dans votre flux de développement local vous-même.

Cela peut être fait en se rendant dans le dossier de votre projet cloné et en exécutant `pre-commit install`.
Ce faisant, git exécutera les vérifications de pre-commit à chaque commit que vous effectuez,
en annulant le commit lui-même si un hook a donné l'alarme.

Vous pouvez également, par exemple, exécuter les hooks de pre-commit à tout moment en exécutant `pre-commit run --all-files`.
====


== 💪 Contribuer
https://open.vscode.dev/jonaspammer/ansible-role-bootstrap[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Ouvrir dans Visual Studio Code]]
image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs Bienvenus]

// Inclus dans README.adoc
:toc:
:toclevels: 3

Les sections suivantes sont de nature générique et sont utilisées pour aider les nouveaux contributeurs.
La "Documentation de développement" réelle de ce projet se trouve sous <<development>>.

=== Préambule
Tout d'abord, merci de considérer contribuer à ce projet.

Suivre ces consignes aide à communiquer que vous respectez le temps des développeurs qui gèrent et développent ce projet open source.
En retour, ils devraient réciproquer ce respect en répondant à votre problème, en évaluant les changements et en vous aidant à finaliser vos demandes de tirage.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Ce projet possédera beaucoup de ses fichiers grâce à
https://github.com/JonasPammer/cookiecutter-ansible-role[le CookieCutter à partir duquel il a été initialement modélisé].

Veuillez vérifier si la modification que vous avez en tête est réellement applicable au modèle
et le cas échéant, apportez un changement approprié là-bas.
Votre changement peut également être partiellement applicable au modèle
ainsi qu'en partie à quelque chose de spécifique à ce projet,
dans quel cas vous créeriez plusieurs PR.

=== 💬 Commits conventionnels

Un contributeur occasionnel n'a pas besoin de s'inquiéter de suivre
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__la spécification__]
https://www.conventionalcommits.org/en/v1.0.0/[__par définition__],
car les demandes de tirage sont fusionnées par lot en un seul commit dans le projet.
Seuls les contributeurs principaux, c'est-à-dire ceux ayant le droit de pousser dans les branches de ce projet, doivent le suivre
(par exemple, pour permettre à la détermination automatique des versions et la génération de journaux de modifications de fonctionner).

=== 🚀 Pour commencer

Les contributions à ce dépôt se font via des problèmes (Issues) et des demandes de tirage (PRs).
Quelques directives générales qui couvrent les deux :

* Recherchez les problèmes et demandes de tirage existants avant de créer les vôtres.
* Si vous n'avez jamais contribué auparavant, consultez https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  le guide pour les nouveaux contributeurs sur le blog d'Auth0] pour des ressources et des conseils sur la façon de commencer.

==== Problèmes

Les problèmes doivent être utilisés pour signaler des problèmes, demander une nouvelle fonctionnalité, ou discuter des changements potentiels *avant* qu'une PR ne soit créée.
Lorsque vous https://github.com/JonasPammer/ansible-role-bootstrap/issues/new[
créez un nouveau problème], un modèle se chargera qui vous guidera dans la collecte et la fourniture des informations nécessaires pour enquêter.

Si vous trouvez un problème qui correspond au problème que vous rencontrez,
merci d'ajouter vos propres informations de reproduction au problème existant *plutôt que d'en créer un nouveau*.
Ajouter une https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[réaction]
peut également aider à indiquer à nos responsables qu'un problème particulier affecte plus que le simple rapporteur.

==== Demandes de tirage

Les PR de ce projet sont toujours les bienvenues et peuvent être un moyen rapide de faire intégrer votre correction ou amélioration dans la prochaine version.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[En général], les PR doivent :

* Seule la fonctionnalité en question *OU* des problèmes de style/espaces vides répandus doivent être corrigés/ajoutés, pas les deux.
* Ajouter des tests unitaires ou d'intégration pour la fonctionnalité corrigée ou modifiée (si une suite de tests existe déjà).
* *Traiter une seule préoccupation*
* *Inclure une documentation* dans le dépôt
* Être accompagnée d'un modèle de demande de tirage complet (chargé automatiquement lorsque qu'une PR est créée).

Pour les changements qui traitent de la fonctionnalité de base ou nécessiteraient des modifications majeures (par exemple, une grande version),
il est préférable d'ouvrir un problème pour discuter de votre proposition d'abord.

En général, nous suivons le flux de travail Git "fork-and-pull"

1. Fork le dépôt sur votre propre compte Github
2. Clonez le projet sur votre machine
3. Créez une branche localement avec un nom succinct mais descriptif
4. Commitez les changements dans la branche
5. Suivez les directives de mise en forme et de test spécifiques à ce dépôt
6. Poussez les changements sur votre fork
7. Ouvrez une PR dans notre dépôt et suivez le modèle de PR afin que nous puissions examiner les changements efficacement.


[[changelog]]
== 🗒 Journal des modifications
Veuillez vous référer à la
https://github.com/JonasPammer/ansible-role-bootstrap/releases[Page de Release de ce dépôt]
pour un journal des modifications humain correspondant aux
https://github.com/JonasPammer/ansible-role-bootstrap/tags[Tags (Versions) de ce projet].

Notez que ce projet suit le Versionnage Sémantique.
Veuillez signaler tout changement accidentel entrainant une rupture de la compatibilité d'une mise à jour mineure.


== ⚖️ Licence

.link:LICENSE[]
----
Licence MIT

Copyright (c) 2022, Jonas Pammer

La permission est accordée, sans frais, à toute personne obtenant une copie
de ce logiciel et de ses fichiers de documentation associés (le "Logiciel"), de traiter
le Logiciel sans restriction, y compris sans limitation les droits
de l'utiliser, de le copier, de le modifier, de le fusionner, de le publier, de le distribuer, de le sous-licencier et/ou de vendre
des copies du Logiciel, et de permettre aux personnes à qui le Logiciel est
fournit de le faire, sous réserve des conditions suivantes :

Le droit d'auteur ci-dessus et cette note de permission doivent être inclus dans toutes
les copies ou portions substantielles du Logiciel.

LE LOGICIEL EST FOURNI "TEL QUEL", SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU
IMPLICITE, Y COMPRIS MAIS NON LIMITÉE AUX GARANTIES DE COMMERCIALISATION,
D'ADÉQUATION À UN USAGE PARTICULIER ET DE NON-VIOLATION. EN AUCUN CAS LES
AUTEURS OU DÉTENTEURS DU DROIT D'AUTEUR NE POURRONT ÊTRE RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGES OU AUTRE
RESPONSABILITÉ, QUE CE SOIT DANS UNE ACTION CONTRACTUELLE, DÉLICTUELLE OU AUTRE, RÉSULTANT DE,
OU EN LIEN AVEC LE LOGICIEL OU L'UTILISATION OU D'AUTRES DEALINGS DANS LE
LOGICIEL.
----