jonaspammer.core_dependencies

Voici la traduction du texte en français :

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

https://galaxy.ansible.com/jonaspammer/core_dependencies[image:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.core_dependencies-brightgreen[Version sur Galaxy]]
// Badges de statut très pertinents
https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml/badge.svg[Tests CI]]

Un rôle Ansible pour installer les packages système nécessaires
pour le bon fonctionnement de divers modules principaux d'Ansible, à savoir :

* `ansible.builtin.apt_repository`
* `ansible.builtin.archive`
* `ansible.builtin.debconf`
* `ansible.builtin.dnf`
* `ansible.builtin.git`
* `ansible.builtin.subversion`
* `ansible.builtin.unarchive`
* `ansible.builtin.user`
* `ansible.builtin.yum`
* `ansible.posix.seboolean`

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

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

[NOTE]
.DÉCLARATION
=====
Ce rôle est un fork de https://github.com/robertdebock/ansible-role-core_dependencies/releases/tag/2.1.9[robertdebock/ansible-role-core_dependencies v2.1.9 sur GitHub (11 fév 2022)] (https://github.com/robertdebock/ansible-role-core_dependencies/compare/2.1.9...master[comparer les modifications depuis ici])
(Licence Apache 2.0, Droits d'auteur Robert de Bock ([email protected])),
pour l'instant juste avec des commentaires de code ajoutés.
=====

toc::[]

[[meta]]
== 🔎 Métadonnées
Ci-dessous, vous trouverez des informations sur…

* la version Ansible requise pour le rôle
* les plateformes prises en charge 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: "core_dependencies"
  description:
    "Un rôle Ansible pour installer des dépendances pour supporter les modules principaux d'Ansible.
    Basé sur le rôle core_dependencies de robertdebock."

  author: "jonaspammer"
  license: "MIT"

  min_ansible_version: "2.11"
  platforms:
    # remarque : le texte après "actively tested : " 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: []

dependencies: []
----

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

La https://galaxy.ansible.com/community/general[`collection community.general`]
doit être installée sur le contrôleur Ansible.

[[variables]]
== 📜 Variables du rôle
// Une description des variables configurables pour ce rôle doit aller ici
// ainsi que toute variable qui peut/doit être définie via des paramètres pour le rôle.
// Toute variable lue à partir d'autres rôles et/ou du scope global (c'est-à-dire hostvars, vars de groupe, etc.)
// doit également être mentionnée ici.

[[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 que par `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 de tâches utilisant des é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] suivantes :

[cols="1,1"]
|===
|Étiquette | 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 sauter des tâches, ou seulement exécuter certaines tâches en utilisant ces étiquettes. Par défaut, toutes les tâches sont exécutées lorsqu'aucune étiquette n'est spécifiée.

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

[[example_playbooks]]
== 📚 Exemples d'utilisation de Playbook
// Inclure des exemples d'utilisation de ce rôle dans un playbook pour des scénarios courants est toujours utile pour les utilisateurs.

[NOTE]
====
Ce rôle fait partie de https://github.com/JonasPammer/ansible-roles[
de nombreux rôles spécifiquement compatibles de ma part].

La machine doit être préparée.
Dans CI, cela se fait dans `molecule/resources/prepare.yml`
qui source ses dépendances logicielles à partir de `requirements.yml` :

.link:molecule/resources/prepare.yml[]
[source,yaml]
----
---
- name: prepare
  hosts: all
  become: true
  gather_facts: false

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

Le diagramme suivant est une compilation des "dépendances logicielles" de ce rôle
ainsi que de l'arbre récursif de leurs dépendances logicielles.

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_core_dependencies.svg[
graphique de dépendance requirements.yml de jonaspammer.core_dependencies]
====

.Jeu jouable minimal
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Préparer des machines Linux à gérer par Ansible.
  gather_facts: false

  roles:
    - role: jonaspammer.core_dependencies
-----
====

.Jeu plus courant
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Préparer des machines Linux à gérer par Ansible.
  become: false
  gather_facts: false

  roles:
    - role: jonaspammer.bootstrap
    - role: jonaspammer.core_dependencies
      become: "{{ bootstrap_become | default(omit) }}"
      become_user: "{{ bootstrap_become_user | default(omit) }}"
-----
====

[[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 - le 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 | Fin de vie de la distribution | Image Docker associée

// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 déguisé])
| 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 Ansible testées

Les versions d'ansible testées essaient de rester équivalentes avec le
https://github.com/ansible-collections/community.general#tested-with-ansible[
schéma de support de la collection `community.general` d'Ansible].
Au moment de l'écriture, cela est :

* 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-core_dependencies/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-core_dependencies/master.svg[statut pre-commit.ci]]
// image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, lien=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 exigences pip]
nommé `requirements-dev.txt`.
Exemple d'instructions d'installation pour Linux ci-dessous :

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

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

[[development-guidelines]]
=== ℹ️ Lignes directrices pour le développement de rôles Ansible

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

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

[[versioning]]
=== 🔢 Gestion des versions

Les versions sont définies en utilisant https://git-scm.com/book/en/v2/Git-Basics-Tagging[Des Tags],
qui sont à leur tour 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-core_dependencies/actions/workflows/release-to-galaxy.yml[
un workflow CI GitHub]
(image:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml/badge.svg[Release CI])
s'occupe d'importer le rôle dans mon compte Ansible Galaxy.

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

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

Le test molecule comprend également une étape qui analyse tous les playbooks ansible à l'aide de
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
pour vérifier les meilleures pratiques et le comportement qui pourrait potentiellement être amélioré.

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

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

Pour une liste de valeurs possibles à donner à `MOLECULE_DISTRO`,
jetez un œil à la matrice définie dans link:.github/workflows/ci.yml[].

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

1. Exécutez vos tests de molecule avec l'option `MOLECULE_DESTROY=never`, par exemple :
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TÂCHE [ansible-role-pip : (redigé).] passage : [************************]
  échoué : [instance-py3-ansible-9] => changed=false
...
 passage : [___________________________________ résumé ____________________________________]
  pré-commit : les commandes ont réussi
ERREUR :   py3-ansible-9 : les commandes ont échoué
----

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

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

root@instance-py3-ansible-2:/#
----
+
[CONSEIL]
====
Si l'échec que vous essayez de déboguer fait partie de votre étape `verify.yml` et non du `converge.yml` réel,
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 à la fois sur le provisionneur et à l'intérieur de la machine docker sous :
* `/var/tmp/vars.yml` (contient les variables hôtes sous la clé `hostvars`)
* `/var/tmp/environment.yml`
Utilisez `grep`, `cat` ou transférez-les comme bon vous semble !
====
+
[CONSEIL]
=====
Vous voudrez également savoir que les fichiers mentionnés dans l'avertissement ci-dessus
sont attachés aux *artifacts CI GitHub* d'un run de workflow donné. +
Cela permet de vérifier la différence entre les exécutions
et ainsi aider à déboguer ce qui a causé la dégradation ou la défaillance 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 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 des packages installés localement

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

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

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

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

Ce conteneur permet même de lancer des conteneurs Docker à l'intérieur (Docker-in-Docker, dind),
permettant ainsi l'exécution de molecule.

Pour l'utiliser :

1. Assurez-vous de répondre aux link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
exigences système des conteneurs de développement Visual Studio Code],
en consultant éventuellement la section __Installation__ de la page liée. +
Cela inclut : Installer Docker, Installer Visual Studio Code lui-même, et Installer 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 le dossier…_).
4. Si vous recevez une invite dans le coin inférieur droit informant de la présence de la définition de devcontainer,
vous pouvez appuyer sur le bouton d'accompagnement pour y entrer.
*Sinon,* vous pouvez également exécuter vous-même la commande Visual Studio `Remote-Containers: Open Folder in Container` (_Affichage - Palette de commandes_ -> _taper dans la commande mentionnée_).

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

[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 maintenu en synchronisation avec
https://github.com/JonasPammer/cookiecutter-ansible-role[le CookieCutter dont il a été initialement templatisé]
en utilisant https://github.com/cruft/cruft[cruft] (si possible) ou un ajustement manuel (si nécessaire)
dans la mesure du 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é, un GitHub Release approprié sera créé
par le responsable 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 hooks https://pre-commit.com/[`pre-commit`], au moins jusqu'à un certain point.

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 Pull Requests sont même automatiquement corrigées par le même outil,
au moins par les hooks qui altèrent automatiquement les fichiers.

[NOTE]
====
À ne pas confondre :
Bien que certains hooks de pré-commit puissent être en mesure de vous avertir des défauts de syntaxe analysés par le script ou même du code à un certain degré (pourquoi les hooks de pré-commit sont *partie de* la suite de tests),
le pré-commit lui-même ne lance pas de vraies suites de tests.
Pour des informations sur les tests, voir <<testing>>.
====

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

Cela peut être fait en vous rendant dans le répertoire de votre projet cloné et en exécutant `pre-commit install`.
Cela fera en sorte que git exécute des vérifications de pré-commit à chaque commit que vous effectuez,
interrompant les commits eux-mêmes si un hook a déclenché une alarme.

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

[[contributing]]
== 💪 Contribuer
https://open.vscode.dev/JonasPammer/ansible-role-core_dependencies[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érale 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 directives aide à communiquer que vous respectez le temps des développeurs gérant et développant ce projet open source.
En retour, ils devraient reciprocally [respecter ce temps] en s’occupant de votre problème, en évaluant les changements, et en vous aidant à finaliser vos demandes de tirage (pull requests).

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Ce projet possède plusieurs fichiers qui proviennent de
https://github.com/JonasPammer/cookiecutter-ansible-role[le CookieCutter dont il a été initialement templatisé].

Veuillez vérifier si la modification que vous envisagez est réellement applicable au gabarit
et si oui, faites un changement approprié là-bas au lieu.
Votre modification peut également être partiellement applicable au gabarit
ainsi qu'en partie à quelque chose de spécifique à ce projet,
dans quel cas vous créeriez plusieurs PRs.

=== 💬 Commits conventionnels

Un contributeur occasionnel n’a pas à 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/[__en théorie__],
puisque les demandes de tirage sont fusionnées par lots dans un seul commit dans le projet.
Seuls les contributeurs principaux, c'est-à-dire ceux qui ont le droit de pousser sur les branches de ce projet, doivent le suivre
(pour permettre à la détermination automatique de la version et à la génération de journaux des modifications de fonctionner).

=== 🚀 Commencer

Les contributions sont faites à ce dépôt via des problèmes et des demandes de tirage (PRs).
Voici quelques directives générales qui couvrent les deux :

* Recherchez les problèmes et les PRs existants avant de créer le vôtre.
* 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 premiers 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 de modifications potentielles *avant* qu'une PR ne soit créée.
Lorsque vous https://github.com/JonasPammer/ansible-role-core_dependencies/issues/new[
créez un nouveau Problème], un gabarit sera chargé qui vous guidera dans la collecte et la fourniture des informations dont nous avons besoin pour enquêter.

Si vous trouvez un Problème qui traite du problème que vous rencontrez,
veuillez ajouter vos propres informations de reproduction au problème existant *plutôt que de 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 mainteneurs qu'un problème particulier affecte plus que le simple rapporteur.

==== Demandes de tirage

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

* Se limiter à corriger/ajouter la fonctionnalité en question *OU* s'attaquer à des problèmes répandus de style d'espacement/formatage, pas les deux.
* Ajouter des tests unitaires ou d'intégration pour les fonctionnalités fixées ou modifiées (si une suite de tests existe déjà).
* *Traiter d'un seul sujet*
* *Inclure de la documentation* dans le dépôt
* Être accompagnée d'un gabarit complet de demande de tirage (chargé automatiquement lorsque qu'une PR est créée).

Pour les changements qui traitent des fonctionnalités principales ou qui nécessiteraient des changements rupturaux (par exemple, une version majeure),
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. Forkez le dépôt sur votre compte Github
2. Clonez le projet sur votre machine
3. Créez une branche localement avec un nom succinct mais descriptif
4. Engagez les modifications sur la branche
5. Suivez toutes les lignes directrices de formatage et de test spécifiques à ce dépôt
6. Poussez les modifications vers votre fork
7. Ouvrez une PR dans notre dépôt et suivez le gabarit de PR pour que nous puissions évaluer les changements de manière efficace.

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

Notez que ce projet respecte la gestion sémantique des versions.
Veuillez signaler toute rupture accidentelle de compatibilité d'une mise à jour de version mineure.

[[license]]
== ⚖️ Licence

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

Droits d'auteur (c) 2022, Jonas Pammer

La permission est par la présente accordée, gratuitement, à toute personne obtenant une copie
de ce logiciel et des fichiers de documentation associés (le "Logiciel"), de traiter
dans le Logiciel sans restriction, y compris sans limitation les droits
à utiliser, copier, modifier, fusionner, publier, distribuer, sous-licencier et/ou vendre
des copies du Logiciel, et à permettre à des personnes auxquelles le Logiciel est
fourni de le faire, sous réserve des conditions suivantes :

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

LE LOGICIEL EST FOURNI "EN L'ÉTAT", SANS GARANTIE D'AUCUNE SORTE, EXPRESSE OU
IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, LES GARANTIES DE COMMERCIALISATION,
D'ADAPTATION À UN OBJECTIF PARTICULIER ET DE NON-RUPTURE. EN AUCUN CAS, LES
AUTEURS OU DÉTENTEURS DES DROITS D'AUTEUR NE PEUVENT ÊTRE TENUS RESPONSABLES DE TOUTE RÉCLAMATION, DOMMAGE OU AUTRE
RESPONSABILITÉ, QUE CE SOIT EN ACTION DE CONTRAT, TORT OU AUTRE, RÉSULTANT DE,
OU EN RELATION AVEC LE LOGICIEL OU L'UTILISATION OU AUTRES TRAITEMENTS DANS LE
LOGICIEL.

----

J'espère que cette traduction répond à vos attentes !