jonaspammer.core_dependencies

// Diese Datei wird von .github/workflows/gh-pages.yml generiert - alle lokalen Änderungen gehen letztendlich verloren!
= ansible-role-core_dependencies
Jonas Pammer <opensource@jonaspammer.at>;
:toc: left
: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 auf Galaxy]]
// Sehr relevante Status-Abzeichen
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[Testen CI]]

Eine Ansible-Rolle zum Installieren der erforderlichen Systempakete, die für die ordnungsgemäße Ausführung verschiedener Ansible-Kernmodule benötigt werden, nämlich:

* `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`

Diese Rolle sorgt außerdem für einen aktuellen Paket-Cache für die meisten Systeme.

In den meisten Fällen möchten Sie diese Rolle in Kombination mit meiner
https://github.com/JonasPammer/ansible-role-bootstrap[`bootstrap`-Rolle] verwenden.

[HINWEIS]
.DISCLAIMER
=====
Diese Rolle ist ein Fork von https://github.com/robertdebock/ansible-role-core_dependencies/releases/tag/2.1.9[robertdebock/ansible-role-core_dependencies v2.1.9 auf GitHub (11. Feb. 2022)] (https://github.com/robertdebock/ansible-role-core_dependencies/compare/2.1.9...master[Änderungen seit hier vergleichen])
(Lizenz Apache 2.0, Copyright Robert de Bock (robert@meinit.nl)),
vorerst nur mit hinzugefügten Codekommentaren.
=====

toc::[]

[[meta]]
== 🔎 Metadaten
Hier finden Sie Informationen zu…

* der erforderlichen Ansible-Version der Rolle
* den unterstützten Plattformen der Rolle
* den https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[Rollenabhängigkeiten]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: "core_dependencies"
  description:
    "Eine Ansible-Rolle zur Installation der Abhängigkeiten zur Unterstützung der Ansible-Kernmodule.
    Basierend auf der core_dependencies-Rolle von robertdebock."

  author: "jonaspammer"
  license: "MIT"

  min_ansible_version: "2.11"
  platforms:
    - name: EL # (Enterprise Linux)
      versions:
        - "9" # aktiv getestet: rockylinux9
    - name: Fedora
      versions:
        - "38" # aktiv getestet: fedora38
        - "39" # aktiv getestet: fedora39
    - name: Debian
      versions:
        - bullseye # aktiv getestet: debian11
        - bookworm # aktiv getestet: debian12
    - name: Ubuntu
      versions:
        - focal # aktiv getestet: ubuntu2004
        - jammy # aktiv getestet: ubuntu2204

  galaxy_tags: []

dependencies: []
----

[[requirements]]
== 📌 Anforderungen
// Alle Voraussetzungen, die möglicherweise nicht von dieser Rolle oder Ansible selbst abgedeckt werden, sollten hier erwähnt werden.
Der Ansible-Benutzer muss in der Lage sein, `become` zu verwenden.

Die https://galaxy.ansible.com/community/general[`community.general` Sammlung]
muss auf dem Ansible-Controller installiert sein.

[[variables]]
== 📜 Rollen-Variablen
// Eine Beschreibung der einstellbaren Variablen für diese Rolle sollte hier angegeben werden
// und alle Variablen, die über Parameter für die Rolle gesetzt werden können/sollten.
// Alle Variablen, die aus anderen Rollen und/oder dem globalen Scope (d.h. hostvars, Gruppenspezifische Variablen usw.)
// stammen, sollten hier ebenfalls erwähnt werden.

[[public_vars]]
== 📜 Fakten/Variablen, die von dieser Rolle definiert sind

Jede in diesem Abschnitt aufgeführte Variable
wird dynamisch definiert, wenn diese Rolle ausgeführt wird (und kann nur mit `ansible.builtin.set_facts` überschrieben werden) _und_
soll nicht nur intern verwendet werden.


[[tags]]
== 🏷️ Tags

// Schauen Sie sich https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// für ein tolles Beispiel für das Gruppieren von Aufgaben an, die Tags verwenden.

Aufgaben sind mit den folgenden
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[Tags] gekennzeichnet:

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

2+| Diese Rolle hat derzeit keine offiziell dokumentierten Tags.

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

Sie können Ansible verwenden, um Aufgaben zu überspringen oder nur bestimmte Aufgaben auszuführen, indem Sie diese Tags verwenden. Standardmäßig werden alle Aufgaben ausgeführt, wenn keine Tags angegeben sind.

[[dependencies]]
== 👫 Abhängigkeiten
// Eine Liste anderer Rollen sollte hier aufgeführt sein,
// sowie alle Details zu Parametern, die möglicherweise für andere Rollen gesetzt werden müssen,
// oder Variablen, die von anderen Rollen verwendet werden.

[[example_playbooks]]
== 📚 Beispiele für Playbook-Nutzungen
// Es ist immer schön für Benutzer, Beispiele anzugeben, wie man diese Rolle in einem Playbook für gängige Szenarien verwendet.

[HINWEIS]
====
Diese Rolle ist Teil von https://github.com/JonasPammer/ansible-roles[
vielen kompatiblen, zweckgebundenen Rollen von mir].

Die Maschine muss vorbereitet werden.
In CI geschieht dies in `molecule/resources/prepare.yml`
die ihre weichen Abhängigkeiten aus `requirements.yml` lädt:

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

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

Das folgende Diagramm ist eine Zusammenstellung der "weichen Abhängigkeiten" dieser Rolle
sowie des rekursiven Baums ihrer weichen Abhängigkeiten.

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_core_dependencies.svg[
Graph der Abhängigkeiten requirements.yml von jonaspammer.core_dependencies]
====

.Minimale brauchbare Play
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Linux-Maschinen zur Verwaltung durch Ansible bootstrappen.
  gather_facts: false

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

.Häufiger genutztes Play
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Linux-Maschinen zur Verwaltung durch Ansible bootstrappen.
  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]]
== 🧪 Getestete Distributionen

Eine Rolle kann auf verschiedenen *Distributionen* funktionieren, wie z.B. Red Hat Enterprise Linux (RHEL),
auch wenn es keinen Test für diese genaue Distribution gibt.
// gute Referenz für das, was zu folgen ist - das am meisten gestarterte und gepinnte Projekt von geerlingguy:
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| OS-Familie | Distribution | Veröffentlichungsdatum der Distribution | Enddatum der Distribution | Begleitendes Docker-Image

// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 im Verborgenen])
| 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 Monate)
| 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]]
== 🧪 Getestete Ansible-Versionen

Die getesteten Ansible-Versionen versuchen, mit dem
https://github.com/ansible-collections/community.general#tested-with-ansible[
Unterstützungsmuster der `community.general` Sammlung von Ansible] übereinzustimmen.
Zum Zeitpunkt des Schreibens ist dies:

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


[[development]]
== 📝 Entwicklung
// Abzeichen zu den Konventionen dieses Projekts
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[pre-commit.ci Status]]

// 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]]
=== 📌 Entwicklungsmaschinen-Abhängigkeiten

* Python 3.10 oder höher
* Docker

[[development-dependencies]]
=== 📌 Entwicklungsabhängigkeiten
Entwicklungsabhängigkeiten sind in einer
https://pip.pypa.io/en/stable/user_guide/#requirements-files[pip-Anforderungsdatei]
namens `requirements-dev.txt` definiert.
Beispiel-Installationsanleitungen für Linux sind unten gezeigt:

----
# "optional": Erstellen Sie ein Python-Virtualenv und aktivieren Sie es für die aktuelle Shell-Sitzung
$ python3 -m venv venv
$ source venv/bin/activate

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

[[development-guidelines]]
=== ℹ️ Ansible-Rollen-Entwicklungsrichtlinien

Bitte sehen Sie sich meine https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Ansible-Rollen-Entwicklungsrichtlinien] an.

Wenn Sie interessiert sind, habe ich auch einige
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Allgemeine Ansible-Rollen-Entwicklung (Best) Praktiken] niedergeschrieben.

[[versioning]]
=== 🔢 Versionierung

Versionen werden mit https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tags] definiert,
die von Ansible Galaxy https://galaxy.ansible.com/docs/contributing/version.html[erkannt und verwendet] werden.

*Versionen dürfen nicht mit `v` beginnen.*

Wenn ein neuer Tag gepusht wird, kümmert sich https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml[
ein GitHub-CI-Workflow]
(image:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml/badge.svg[Release CI])
um das Importieren der Rolle in mein Ansible Galaxy-Konto.

[[testing]]
=== 🧪 Testen
Automatische Tests werden bei jedem Beitrag mit GitHub-Workflows ausgeführt.

Die Tests konzentrieren sich hauptsächlich auf die Ausführung von https://molecule.readthedocs.io/en/latest/[Molecule]
auf einer <<tested-distributions,variierten Reihe von Linux-Distributionen>>
und der Verwendung von <<tested-ansible-versions,various ansible versions>>.

Der Molecule-Test beinhaltet auch einen Schritt, der alle Ansible-Playbooks mit
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
lintert, um bewährte Praktiken und Verhaltensweisen zu überprüfen, die möglicherweise verbessert werden könnten.

Um die Tests auszuführen, führen Sie einfach `tox` in der Befehlszeile aus.
Sie können eine optionale Umgebungsvariable übergeben, um die Distribution des
Docker-Containers zu definieren, der von Molecule erstellt wird:

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

Für eine Liste von möglichen Werten, die an `MOLECULE_DISTRO` übergeben werden, werfen Sie einen Blick auf die Matrix, die in link:.github/workflows/ci.yml[] definiert ist.

==== 🐛 Debugging eines Molecule-Containers

1. Führen Sie Ihre Molecule-Tests mit der Option `MOLECULE_DESTROY=never` aus, z.B.:
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TASK [ansible-role-pip : (redacted).] pass:[************************]
  failed: [instance-py3-ansible-9] => changed=false
...
 pass:[___________________________________ summary ____________________________________]
  pre-commit: commands succeeded
ERROR:   py3-ansible-9: commands failed
----

2. Finden Sie den Namen des von Molecule bereitgestellten Docker-Containers:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   vor 8 Minuten   Vor 8 Minuten                                                                                                    instance-py3-ansible-9
----

3. Gehen Sie in eine Bash-Shell des Containers und führen Sie Ihr Debugging durch:
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*

root@instance-py3-ansible-2:/#
----
+
[TIPP]
====
Wenn der Fehler, den Sie debuggen möchten, Teil Ihres `verify.yml`-Schrittes und nicht des tatsächlichen `converge.yml` ist,
möchten Sie möglicherweise wissen, dass die Ausgaben von Ansibles Modulen (`vars`), Hosts (`hostvars`) und
Umgebungsvariablen in Dateien auf dem Provisioner und innerhalb der Docker-Maschine unter gespeichert wurden:
* `/var/tmp/vars.yml` (enthält Hostvariablen unter dem Schlüssel `hostvars`)
* `/var/tmp/environment.yml`
`grep`, `cat` oder übertragen Sie diese, wie Sie möchten!
====
+
[TIPP]
=====
Sie möchten möglicherweise auch wissen, dass die oben genannten Dateien
den *GitHub-CI-Artefakten* eines bestimmten Workflow-Laufs angehängt sind. +
Dies ermöglicht es Ihnen, die Unterschiede zwischen den Läufen zu überprüfen
und somit beim Debuggen zu helfen, was den Bitrot oder den Fehler im Allgemeinen verursacht hat.

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

4. Nachdem Sie Ihre Debugging-Durchläufe abgeschlossen haben, beenden Sie dies und zerstören den Container:
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*

$ *docker stop #30e9b8d59cdf#*

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

==== 🐛 Debugging installierter Paketversionen lokal

Obwohl dies eine Standardfunktion in tox 3 ist, https://github.com/tox-dev/tox/pull/2794[now] geschieht dies nur, wenn tox die Anwesenheit einer CI-Variablen erkennt.
Zum Beispiel:

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


[[development-container-extra]]
=== 🧃 TIPP: Containerisierte ideale Entwicklungsumgebung

Dieses Projekt bietet eine Definition für eine "1-Klick-containerisierte Entwicklungsumgebung".

Dieser Container ermöglicht es sogar, Docker-Container innerhalb davon auszuführen (Docker-in-Docker, dind),
was die Ausführung von Molecule ermöglicht.

Um es zu verwenden:

1. Stellen Sie sicher, dass Sie die link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   Systemanforderungen der Visual Studio Code Development Containers] erfüllen,
   optional die __Installations__-Sektion des verlinkten Seitenabschnitts befolgen. +
   Dazu gehört: Docker installieren, Visual Studio Code selbst installieren und die erforderliche Erweiterung installieren.
2. Klonen Sie das Projekt auf Ihren Computer
3. Öffnen Sie den Ordner des Repos in Visual Studio Code (_Datei - Ordner öffnen…_).
4. Wenn Sie eine Aufforderung in der unteren rechten Ecke erhalten, die über das Vorhandensein der devcontainer-Definition informiert,
können Sie die begleitende Schaltfläche drücken, um einzutreten.
*Ansonsten* können Sie auch den Visual Studio-Befehl `Remote-Containers: Open Folder in Container` selbst ausführen (_Ansicht - Befehlspalette_ -> _geben Sie den genannten Befehl ein_).

[TIPP]
====
Ich empfehle, `Remote-Containers: Rebuild Without Cache and Reopen in Container`
gelegentlich zu verwenden, da die devcontainer-Funktion manchmal Probleme hat, korrekt erkannte Änderungen
an ihrer Definition.
====

[HINWEIS]
=====
Möglicherweise müssen Sie Ihr Hosts-System so konfigurieren, dass der Container Ihre SSH/GPG-Keys verwenden kann.

Das Verfahren ist in den offiziellen Devcontainer-Dokumenten unter "Teilen von Git-Anmeldeinformationen mit Ihrem Container" beschrieben.
https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
in der offiziellen devcontainer docs] konfiguriert.
=====


[[cookiecutter]]
=== 🍪 CookieCutter

Dieses Projekt soll mit
https://github.com/JonasPammer/cookiecutter-ansible-role[dem CookieCutter, von dem es ursprünglich erstellt wurde] synchronisiert werden,
unter Verwendung von https://github.com/cruft/cruft[cruft] (wenn möglich) oder manueller Änderung (wenn nötig)
so gut wie möglich.

.Offizielles Beispiel zur Verwendung von `cruft update`
____
image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Offizielles Beispiel zur Verwendung von `cruft update`]
____

==== 🕗 Änderungsprotokoll
Wenn ein neuer Tag gepusht wird, wird ein entsprechendes GitHub-Release vom Repository-Maintainer erstellt,
um ein richtiges menschliches Änderungsprotokoll mit Titel und Beschreibung bereitzustellen.

[[pre-commit]]
=== ℹ️ Allgemeine Linting- und Styling-Konventionen
Allgemeine Linting- und Styling-Conventions werden
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automatisch* auf Standards] 
von verschiedenen https://pre-commit.com/[`pre-commit`] Hooks, zumindest teilweise, eingehalten.

Die automatische Ausführung von pre-commit erfolgt bei jedem Beitrag mit
https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Pull-Requests werden sogar automatisch von demselben Tool behoben,
zumindest von Hooks, die automatisch Dateien ändern.

[HINWEIS]
====
Nicht verwirren:
Obwohl einige pre-commit-Hooks Sie möglicherweise über script-analysierte Fehler in der Syntax oder sogar im Code bis zu einem gewissen Grad informieren können (aus welchem Grund pre-commit-Hooks *Teil von* der Test-Suite sind),
führt pre-commit selbst keine echten Test-Suiten aus.
Siehe <<testing>> für Informationen über Tests.
====

[TIPP]
====
[[note_pre-commit-ci]]
Ich empfehle Ihnen jedoch, pre-commit selbst in Ihren lokalen Entwicklungsworkflow zu integrieren.

Dies kann erreicht werden, indem Sie in das Verzeichnis Ihres geklonten Projekts wechseln und `pre-commit install` ausführen.
Dadurch wird Git dazu gebracht, pre-commit-Überprüfungen bei jedem Commit auszuführen,
die selbst die Commits abbrechen, wenn ein Hook Alarm schlägt.

Sie können auch beispielsweise die Hooks von pre-commit jederzeit ausführen, indem Sie `pre-commit run --all-files` ausführen.
====


[[contributing]]
== 💪 Mitwirken
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[In Visual Studio Code öffnen]]
image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs Willkommen]

// In README.adoc enthalten
:toc:
:toclevels: 3

Die folgenden Abschnitte sind generischer Natur und helfen neuen Mitwirkenden.
Die tatsächliche "Entwicklungsdokumentation" dieses Projekts finden Sie unter <<development>>.

=== 🤝 Einleitung
Zunächst einmal vielen Dank, dass Sie in Betracht ziehen, zu diesem Projekt beizutragen.

Das Befolgen dieser Richtlinien hilft, zu kommunizieren, dass Sie die Zeit der Entwickler respektieren, die dieses Open-Source-Projekt verwalten und entwickeln.
Im Gegenzug sollten sie diesen Respekt erwidern, indem sie Ihr Problem ansprechen, Änderungen bewerten und Ihnen helfen, Ihre Pull-Requests abzuschließen.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Dieses Projekt gehört zu vielen seiner Dateien
https://github.com/JonasPammer/cookiecutter-ansible-role[dem CookieCutter, von dem es ursprünglich erstellt wurde].

Bitte überprüfen Sie, ob die Änderung, die Sie im Sinn haben, tatsächlich auf die Vorlage anwendbar ist
und ändern Sie gegebenenfalls etwas an der Vorlage.
Ihrer Änderung kann auch teilweise auf die Vorlage
sowie teilweise auf etwas, das spezifisch für dieses Projekt ist, anwendbar sein,
in diesem Fall würden Sie mehrere PRs erstellen.

=== 💬 Konventionelle Commits

Ein gelegentlicher Mitwirkender muss sich keine Sorgen machen, die https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__Spezifikation__]
https://www.conventionalcommits.org/en/v1.0.0/[__per Definition__] einzuhalten,
da Pull-Requests in das Projekt immer zusammengeführt werden,
indem sie in einem Commit zusammengefasst werden.
Nur Hauptmitwirkende, d.h. diejenigen, die das Recht haben, in die Branches dieses Projekts zu pushen, müssen dies beachten
(z.B. um automatische Versionsbestimmung und Änderungsprotokollgenerierung zu ermöglichen).

=== 🚀 Erste Schritte

Beiträge werden in diesem Repo über Issues und Pull Requests (PRs) gemacht.
Einige allgemeine Richtlinien, die beide abdecken:

* Suchen Sie nach bestehenden Issues und PRs, bevor Sie Ihre eigenen erstellen.
* Wenn Sie noch nie zuvor einen Beitrag geleistet haben, sehen Sie sich https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  den Leitfaden für Erstbeiträge auf dem Blog von Auth0] für Ressourcen und Tipps an, wie Sie anfangen können.

==== Issues

Issues sollten verwendet werden, um Probleme zu melden, um eine neue Funktion zu bitten oder um mögliche Änderungen *vor* der Erstellung eines PR zu besprechen.
Wenn Sie https://github.com/JonasPammer/ansible-role-core_dependencies/issues/new[
ein neues Issue erstellen], wird eine Vorlage geladen, die Sie durch das Sammeln und Bereitstellen der Informationen, die wir benötigen, um zu untersuchen, führt.

Wenn Sie ein Issue finden, das das Problem behandelt, das Sie haben,
fühlen Sie sich bitte frei, Ihre eigenen Reproduktionsinformationen zum bestehenden Issue hinzuzufügen *anstatt ein neues zu erstellen*.
Das Hinzufügen einer https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[Reaktion]
kann auch dabei helfen, unseren Betreuern zu zeigen, dass ein bestimmtes Problem mehr als nur den Berichterstatter betrifft.

==== Pull Requests

PRs zu diesem Projekt sind immer willkommen und können eine schnelle Möglichkeit sein, Ihren Fix oder Ihre Verbesserung für das nächste Release einzuplanen.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[Im Allgemeinen] sollten PRs:

* Nur die Funktionalität besprechen/fixen *ODER* weit verbreitete Leerzeichen-/Stilprobleme angehen, nicht beides.
* Unit- oder Integrationstests für gefixte oder geänderte Funktionalität hinzufügen (wenn eine Test-Suite bereits existiert).
* *Ein einziges Anliegen beachten*
* *Dokumentation im Repo enthalten*
* Von einer vollständigen Pull-Request-Vorlage begleitet werden (automatisch geladen, wenn ein PR erstellt wird).

Für Änderungen, die die Kernfunktionalität betreffen oder die brechende Änderungen erfordern würden (z.B. ein großes Release),
ist es am besten, zunächst ein Problem zu eröffnen, um Ihren Vorschlag zu besprechen.

Im Allgemeinen folgen wir dem "Fork-and-Pull"-Git-Workflow

1. Forken Sie das Repository in Ihr eigenes Github-Konto
2. Klonen Sie das Projekt auf Ihren Computer
3. Erstellen Sie lokal einen Branch mit einem kurzen, aber beschreibenden Namen
4. Commiten Sie Änderungen in den Branch
5. Befolgen Sie alle spezifischen Formatierungs- und Testrichtlinien zu diesem Repo
6. Pushen Sie die Änderungen zu Ihrem Fork
7. Öffnen Sie einen PR in unserem Repository und folgen Sie der PR-Vorlage, damit wir die Änderungen effizient überprüfen können.


[[changelog]]
== 🗒 Änderungsprotokoll
Bitte beachten Sie die
https://github.com/JonasPammer/ansible-role-core_dependencies/releases[Release-Seite dieses Repositories]
für ein menschliches Änderungsprotokoll der entsprechenden
https://github.com/JonasPammer/ansible-role-core_dependencies/tags[Tage (Versionen) dieses Projekts].

Beachten Sie, dass dieses Projekt der semantischen Versionierung folgt.
Bitte melden Sie eventuelle versehentlichen brechenden Änderungen eines Minor-Release-Updates.


[[license]]
== ⚖️ Lizenz

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

Copyright (c) 2022, Jonas Pammer

Hiermit wird kostenlos, an jede Person, die eine Kopie
dieser Software und der damit verbundenen Dokumentationsdateien (die "Software") erhält, die Erlaubnis erteilt,
mit der Software ohne Einschränkung zu verfahren, einschließlich ohne Einschränkung der Rechte
zu verwenden, zu kopieren, zu ändern, zusammenzuführen, zu veröffentlichen, zu vertreiben, unterzulizenzieren und/oder 
Kopien der Software zu verkaufen und Personen, denen die Software überlassen wird, dies zu ermöglichen,
unter dem folgenden Vorbehalt:

Der vorgenannte Urheberrechtshinweis und dieser Erlaubnisschein sind in allen
Kopien oder wesentlichen Teilen der Software enthalten.

DIE SOFTWARE WIRD "WIE BESEHEN" BEREITGESTELLT, OHNE GARANTIE JEWEILS ART, WEDER AUSDRÜCKLICH NOCH IMPLIZIT, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE GARANTIEN DER MARKTÜBLICHKEIT,
DER EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND DER NICHTVERLETZUNG. IN KEINEM FALL SIND DIE AUTOREN ODER COPYRIGHT-INHABER FÜR ANSPRUCH, SCHÄDEN ODER SONSTIGE
HAFTUNGEN HAFTBAR, OB IN EINER KLAGE AUS VERTRAG, DELIKT ODER SONSTIGE, DIE AUS
ODER IM ZUSAMMENHANG MIT DER SOFTWARE ODER DER NUTZUNG ODER ANDEREN TRANSAKTIONEN IN DER SOFTWARE ENTSTEHEN.

----