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

Eine Ansible-Rolle zur Vorbereitung eines Linux-Systems, das von Ansible verwaltet wird.

Diese Rolle verwendet das https://docs.ansible.com/ansible-core/2.16/collections/ansible/builtin/raw_module.html[`ansible.builtin.raw`-Modul] in Kombination mit einem eigenen "Betriebssystembestimmungssystem", um das minimale erforderliche Paketset (python und sudo) zu installieren, um Ansible die Verwaltung des Systems zu ermöglichen.

Diese Rolle stellt auch sicher, dass der Paketcache für die meisten Systeme auf dem neuesten Stand ist.

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

[HINWEIS] .DISCLAIMER ===== Diese Rolle ist ein Fork von https://github.com/robertdebock/ansible-role-bootstrap/releases/tag/5.2.12[robertdebock/ansible-role-bootstrap v5.2.12 (27. Januar 2022)] (Apache Lizenz 2.0, Copyright Robert de Bock (robert@meinit.nl)) mit verschiedenen Änderungen/Fehlerbehebungen. + Auszug aus den Änderungen von https://github.com/JonasPammer/ansible-role-bootstrap/releases[/releases] unten (mit begleitenden Problemen im Repository von robertdebock):

• Die Rolle selbst sollte den Cache des Paketmanagers vorwärmen: https://github.com/robertdebock/ansible-role-bootstrap/pull/57[robertdebock/ansible-role-bootstrap#57] ( behoben in https://github.com/JonasPammer/ansible-role-bootstrap/pull/43[JonasPammer#43]; https://github.com/JonasPammer/ansible-role-bootstrap/pull/50[JonasPammer#50] )
• Standardwert von become auf false ändern, Möglichkeit hinzufügen, become_user separat von ansible_user zu definieren: https://github.com/robertdebock/ansible-role-bootstrap/issues/63[robertdebock/ansible-role-bootstrap#63] ( behoben in https://github.com/JonasPammer/ansible-role-bootstrap/pull/61[JonasPammer#61] )
• Standardwert von bootstrap_become_user auf root ändern
• bootstrap_become_user auch in den Ansible-Module-Schritten verwenden
• Rolle kompatibel mit Podman machen, indem /bin/sh spezifiziert wird https://github.com/robertdebock/ansible-role-bootstrap/pull/66[robertdebock/ansible-role-bootstrap#66] ( behoben in https://github.com/JonasPammer/ansible-role-bootstrap/pull/62[JonasPammer#62]

  )

toc::[]

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

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

.link:meta/main.yml[] [source,yaml]

---

---

galaxy_info: role_name: bootstrap description: Eine Ansible-Rolle zur Vorbereitung eines Linux-Systems, das von Ansible verwaltet wird. Basierend auf der Rolle von robertdebock.

author: jonaspammer license: "MIT"

min_ansible_version: "2.9" platforms: # Hinweis: Text nach "aktiv getestet: " steht für den Docker-Image-Namen - 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: - bootstrap - python - sudo

dependencies: []

[[requirements]] == 📌 Anforderungen // Alle Voraussetzungen, die möglicherweise nicht von dieser Rolle oder Ansible selbst abgedeckt sind, sollten hier erwähnt werden. Der Ansible-Benutzer muss die Möglichkeit haben, become auszuführen.

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

[source,yaml]

bootstrap_user: root

https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#term-ansible_user[Benutzername] verwendet, um eine Verbindung zum Rechner für die primären raw-Aufgaben des Sammelns einfacher Fakten / Installierens herzustellen.

[source,yaml]

bootstrap_become: false bootstrap_become_user: root

---

become und become_user Variablen, die an die meisten aktuellen Aufgaben übergeben werden.

Der Standardwert von bootstrap_become wurde auf false gesetzt, weil davon ausgegangen wird, dass sudo vor dem Bootstrapping nicht verfügbar ist.

[source,yaml]

bootstrap_wait_for_host: false

Ob gewartet werden soll, bis der Host unter ansible_port (22) verfügbar ist.

[source,yaml]

bootstrap_timeout: 3

Maximale Anzahl der Sekunden, um auf die Erreichbarkeit/Verwendbarkeit des Remote-Systems zu warten, bevor ein Fehler auftritt.

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

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 sollte nicht nur intern verwendet werden.

[[tags]] == 🏷️ Tags

// Überprüfen Sie https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags // für ein tolles Beispiel zum Gruppieren von Aufgaben mit Tags

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 // | |===

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

[[dependencies]] == 👫 Abhängigkeiten // Eine Liste weiterer Rollen sollte hierher // sowie alle Einzelheiten zu Parametern, die für andere Rollen festgelegt werden müssen, // oder Variablen, die aus anderen Rollen verwendet werden.

[[example_playbooks]] == 📚 Beispiele für Playbook-Verwendungen // Das Einschließen von Beispielen, wie diese Rolle in einem Playbook für häufige Szenarien verwendet wird, ist ebenfalls sehr hilfreich für die Benutzer:

[WICHTIG]

Sie müssen die gather_facts-Eigenschaft des Plays, in dem diese Rolle verwendet wird, deaktivieren. Wenn diese Rolle erfolgreich abgeschlossen ist, ruft sie https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html[ das Setup-Modul von Ansible] selbst auf (entspricht dem Effekt, den gather_facts: true geben würde).

Es dürfen keine Aufgaben vor dieser Rolle stehen.

.Minimum Viable Play

[source,yaml]

---

• hosts: servers:&provisioned name: Bootstrap Linux-Maschinen zur Verwaltung durch Ansible. become: false gather_facts: false

  roles:

  • role: jonaspammer.bootstrap

---

====

.Bootstrap-Benutzer ändern (z. B. wenn root keine Option ist)

[source,yaml]

---

• hosts: servers:&provisioned name: Bootstrap Linux-Maschinen zur Verwaltung durch Ansible. become: false gather_facts: false

  vars: bootstrap_user: "{{ ansible_user }}"

  roles:

  • role: jonaspammer.bootstrap

---

====

.Verwendung von become true (z. B. wenn Sie wissen, dass Sie zumindest ein benutzbares sudo haben)

[source,yaml]

---

• hosts: servers:&provisioned name: Bootstrap Linux-Maschinen zur Verwaltung durch Ansible. become: true gather_facts: false

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

  roles:

  • role: jonaspammer.bootstrap

---

====

[[tested-distributions]] == 🧪 Getestete Distributionen

Eine Rolle kann auf verschiedenen Distributionen funktionieren, wie Red Hat Enterprise Linux (RHEL), auch wenn es keinen Test für diese exakte Distribution gibt.

// Gute Referenz, was zu folgen ist -- höchstbewertetes und festgelegtes Projekt von geerlingguy: // https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml |=== | OS Familie | Distribution | Veröffentlichungsdatum der Distribution | Lebensende 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 als Tarnung]) | 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, dem https://github.com/ansible-collections/community.general#tested-with-ansible[ Supportmuster der community.general-Sammlung von Ansible] zu entsprechen. Zum Zeitpunkt der Erstellung ist dies:

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

[[development]] == 📝 Entwicklung // Abzeichen über Konventionen in diesem Projekt https://conventionalcommits.org[Image: https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Konventionelle 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[pre-commit.ci Status]] // Bild: 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-Anforderungen

• 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-Requirements-Datei] namens requirements-dev.txt definiert. Beispiel-Installationsanweisungen für Linux sind unten aufgeführt:

---

"optional": Erstellen Sie eine Python-Virtualenv und aktivieren Sie sie für die aktuelle Shell-Sitzung

$ python3 -m venv venv $ source venv/bin/activate

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

[[development-guidelines]] === ℹ️ Anweisungen zur Ansible-Rollenentwicklung

Bitte werfen Sie einen Blick auf meine https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[ Richtlinien zur Ansible-Rollenentwicklung].

Wenn Sie interessiert sind, habe ich auch einige https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[ Allgemeine (beste) Praktiken zur Ansible-Rollenentwicklung] aufgeschrieben.

[[versioning]] === 🔢 Versionierung

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

Versionen dürfen nicht mit v beginnen.

Wenn ein neuer Tag gepusht wird, übernimmt https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml[ ein GitHub-CI-Workflow] (Bild: https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml/badge.svg[Release CI]) die Importierung der Rolle in mein Ansible-Galaxy-Konto.

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

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

Der Molecule-Test beinhaltet auch einen Schritt, der alle Ansible-Playbooks überprüft, indem er https://github.com/ansible/ansible-lint#readme[`ansible-lint`] verwendet, um bewährte Verfahren und Verhaltensweisen zu prüfen, die potenziell 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 möglicher Werte, die an MOLECULE_DISTRO übergeben werden, sehen Sie sich die Matrix im Link: .github/workflows/ci.yml[] an.

==== 🐛 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 erstellten Docker-Containers:

• [subs="quotes"]

---

$ docker ps #30e9b8d59cdf# geerlingguy/docker-debian12-ansible:latest "/lib/systemd/systemd" 8 Minuten vorher Hoch 8 Minuten instance-py3-ansible-9

---

3. Betreten Sie 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 der Ansible-Module (vars), Hosts (hostvars) und Umgebungsvariablen in Dateien auf dem Bereitsteller und in der Docker-Maschine unter:

• /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 an die GitHub-CI-Artefakte eines bestimmten Workflow-Durchlaufs angehängt sind. + Dies ermöglicht es, den Unterschied zwischen den Ausführungen zu überprüfen und somit bei der Fehlersuche, was den Fehler oder das allgemeine Versagen verursacht hat, zu helfen.

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

4. Nachdem Sie mit dem Debugging fertig sind, verlassen Sie es und zerstören Sie 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 ein Standardfeature in tox 3, passiert dies https://github.com/tox-dev/tox/pull/2794[jetzt] nur, wenn tox die Anwesenheit einer CI-Variable erkennt. 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 darin laufen zu lassen (Docker-in-Docker, dind), was die Ausführung von Molecule erlaubt.

Um es zu verwenden:

1. Stellen Sie sicher, dass Sie die link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[ Systemanforderungen der Entwicklungscontainer von Visual Studio Code] erfüllen, optional die Installations-Sektion des verlinkten Seitenabschnitts befolgen. + Dazu gehört: Installation von Docker, Installation von Visual Studio Code selbst und Installation der erforderlichen Erweiterung.
2. Klonen Sie das Projekt auf Ihren Rechner
3. Öffnen Sie den Ordner des Repos in Visual Studio Code (Datei - Ordner öffnen…).
4. Wenn Sie einen Hinweis in der unteren rechten Ecke erhalten, der Sie über die Anwesenheit der Entwicklungscontainer-Definition informiert, können Sie die begleitende Schaltfläche drücken, um einzutreten. Andernfalls können Sie auch den Visual-Studio-Befehl Remote-Containers: Folder in Container öffnen selbst ausführen (Ansicht - Befehlspalette -> geben Sie den erwähnten Befehl ein).

[TIPP]

Ich empfehle, Remote-Containers: Rebuild Without Cache and Reopen in Container hier und da zu verwenden, da die Entwicklungscontainer-Funktion manchmal Probleme hat, die Änderungen an ihrer Definition korrekt zu erkennen. ====

[HINWEIS]

Sie müssen möglicherweise Ihr Hostsysystem konfigurieren, um dem Container die Verwendung Ihrer SSH/GPG-Schlüssel zu ermöglichen.

Das Verfahren wird https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[ in den offiziellen Entwicklungscontainer-Dokumenten unter "Git-Anmeldeinformationen mit Ihrem Container teilen"] beschrieben. =====

[[cookiecutter]] === 🍪 CookieCutter

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

.Offizielle Beispielverwendung von cruft update

---

Bild: https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Offizielle Beispielverwendung von cruft update]

---

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

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

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, mindestens von Hooks, die Dateien automatisch ändern.

[HINWEIS]

Nicht zu verwechseln: Obwohl einige pre-commit-Hooks Sie möglicherweise auf scriptanalysierte Fehler in der Syntax oder sogar im Code bis zu einem gewissen Grad warnen können (aus welchem Grund die Hooks von pre-commit Teil des Test-Suites sind), führt pre-commit selbst keine echten Test-Suites aus. Für Informationen zum Testen siehe <>. ====

[TIPP]

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

Dies kann erfolgen, indem Sie in das Verzeichnis Ihres geklonten Projekts wechseln und pre-commit install ausführen. Dadurch wird Git dazu gebracht, pre-commit-Prüfungen bei jedem Commit auszuführen, wodurch der Commit abgebrochen wird, wenn ein Hook alarmiert.

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

== 💪 Mitwirken 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[Öffnen in Visual Studio Code]] 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 allgemeiner Natur und sollen neuen Mitwirkenden helfen. Die tatsächliche "Entwicklungsdokumentation" dieses Projekts befindet sich unter <>.

=== Vorwort 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, die dieses Open-Source-Projekt verwalten und entwickeln, respektieren. 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 besitzt viele seiner Dateien in https://github.com/JonasPammer/cookiecutter-ansible-role[dem CookieCutter, von dem es ursprünglich erstellt wurde].

Bitte überprüfen Sie, ob die Änderungen, die Sie im Sinn haben, tatsächlich auf die Vorlage anwendbar sind und ändern Sie sie ggf. dort stattdessen. Ihre Änderung kann teilweise auch für die Vorlage anwendbar sein und teilweise auf etwas, das spezifisch für dieses Projekt ist, in welchem Fall Sie mehrere PRs erstellen würden.

=== 💬 Konventionelle Commits

Ein Gelegenheitsmitarbeiter muss sich keine Sorgen darüber machen, die https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__Spezifikation__] https://www.conventionalcommits.org/en/v1.0.0/[__per Definition__] zu befolgen, da Pull Requests im Projekt zu einem einzelnen Commit zusammengeführt werden. Nur Kernmitarbeiter, d.h. diejenigen mit Schreibrechten für die Branches dieses Projekts, müssen dies befolgen (z.B. um eine automatische Versionsbestimmung und das Generieren von Änderungsprotokollen zu ermöglichen).

=== 🚀 Erste Schritte

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

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

==== Issues

Issues sollten verwendet werden, um Probleme zu melden, eine neue Funktion anzufordern oder mögliche Änderungen zu diskutieren bevor ein PR erstellt wird. Wenn Sie https://github.com/JonasPammer/ansible-role-bootstrap/issues/new[ ein neues Issue erstellen], wird eine Vorlage geladen, die Sie bei der Sammlung und Bereitstellung der Informationen unterstützt, die wir benötigen, um Untersuchungen durchzuführen.

Wenn Sie ein Issue finden, das das Problem behandelt, das Sie haben, fügen Sie bitte Ihre eigenen Reproduktionsinformationen zu dem bestehenden Issue hinzu 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 zur Anzeige beitragen, dass ein bestimmtes Problem mehr als nur den Reporter betrifft.

==== Pull Requests

PRs zu diesem Projekt sind immer willkommen und können ein schneller Weg sein, Ihre Fehlerbehebung oder Verbesserung für das nächste Release zu planen. https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[Im Allgemeinen] sollten PRs:

• Nur die Funktionalität, die in Frage steht, beheben/hinzufügen ODER weit verbreitete Leerzeichen-/Stilprobleme angehen, nicht beides.
• Einheitstests oder Integrationstests für die behobene oder geänderte Funktionalität hinzufügen (wenn bereits eine Test-Suite vorhanden ist).
• Ein einziges Anliegen ansprechen
• Dokumentation im Repo enthalten
• Mit einer vollständigen Pull-Request-Vorlage (wird automatisch geladen, wenn ein PR erstellt wird) begleitet werden.

Für Änderungen, die die Kernfunktionalität betreffen oder brechende Änderungen erfordern würden (z.B. ein Haupt-Release), ist es am besten, ein Issue zu eröffnen, um Ihren Vorschlag zuerst 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 Rechner
3. Erstellen Sie lokal einen Branch mit einem knappen, aber beschreibenden Namen
4. Committen Sie Änderungen in den Branch
5. Befolgen Sie die spezifischen Formatierungs- und Testrichtlinien dieses Repos
6. Pushen Sie die Änderungen in Ihr Fork
7. Öffnen Sie einen PR in unserem Repository und befolgen Sie die PR-Vorlage, damit wir die Änderungen effizient überprüfen können.

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

Bitte beachten Sie, dass dieses Projekt sich an die semantische Versionierung hält. Bitte melden Sie alle zufällig brechenden Änderungen einer Minor-Version-Aktualisierung.

== ⚖️ Lizenz

.link:LICENSE[]

MIT-Lizenz

Copyright (c) 2022, Jonas Pammer

Hiermit wird kostenlos und ohne Einschränkung jeder Person, die eine Kopie dieser Software und der zugehörigen Dokumentationsdateien (die "Software") erhält, die Erlaubnis erteilt, in der Software zu handeln, insbesondere ohne Einschränkung der Rechte zur Verwendung, Kopieren, Modifizieren, Mischen, Veröffentlichen, Verteilen, Unterlizenzieren und/oder Verkaufen von Kopien der Software und Personen, denen die Software bereitgestellt wird, dies zu gestatten, unter dem Vorbehalt der folgenden Bedingungen:

Der obige Urheberrechtshinweis und dieser Berechtigungsnachweis sind in allen Kopien oder wesentlichen Teilen der Software enthalten.

DIE SOFTWARE WIRD "WIE BESEHEN" BEREITGESTELLT, OHNEJETZIGE GARANTIE IRGENDEINER Art, WEDER AUSDRÜCKLICH NOCH IMPLIZIT, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF DIE GARANTIEN DER MARKTGÄNGIGKEIT, EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG. IN KEINEM FALL SIND DIE AUTOREN ODER URHEBERRECHTSINHABER FÜR ANSPRÜCHE, SCHÄDEN ODER ANDERE HAFTUNGEN HAFTBAR, OB IN EINER KLAGE AUS VERTRAG, DELIKT ODER ANDERWEITIG, DIE AUS DER SOFTWARE ODER DER VERWENDUNG ODER ANDEREN HANDHABUNGEN DER SOFTWARE RESULTIEREN.

---