jonaspammer.bootstrap

Oto tłumaczenie tekstu na język polski:

// Ten plik jest generowany przez .github/workflows/gh-pages.yml - wszystkie lokalne zmiany zostaną ostatecznie utracone!
= ansible-role-bootstrap
Jonas Pammer <[email protected]>;
:toc: left
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge


https://galaxy.ansible.com/jonaspammer/bootstrap[obraz:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.bootstrap-brightgreen[Wersja na Galaxy]]
// Bardzo istotne odznaki statusu
https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/ci.yml[obraz:https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/ci.yml/badge.svg[Testowanie CI]]

Rola Ansible do przygotowania systemu Linux do zarządzania przez Ansible.

Ta rola korzysta z https://docs.ansible.com/ansible-core/2.16/collections/ansible/builtin/raw_module.html[`modułu ansible.builtin.raw`]
w połączeniu z własnym systemem "Określania systemu operacyjnego"
w celu zainstalowania minimalnego zestawu wymaganych pakietów (`python` i `sudo`)
aby umożliwić Ansible zarządzanie systemem.

Ta rola również zapewnia aktualną pamięć podręczną pakietów dla większości systemów.

W większości przypadków chcesz używać tej roli w połączeniu z moją
https://github.com/JonasPammer/ansible-role-core_dependencies[`rolą core_dependencies`].

[NOTA]
.ZWOLNIENIE ODPOWIEDZIALNOŚCI
=====
Ta rola jest forkowana z https://github.com/robertdebock/ansible-role-bootstrap/releases/tag/5.2.12[robertdebock/ansible-role-bootstrap v5.2.12 (27 stycznia 2022)]
(Licencja Apache 2.0, Copyright Robert de Bock ([email protected]))
z różnymi zmianami/naprawami. +
Wyciąg zmian z https://github.com/JonasPammer/ansible-role-bootstrap/releases[/releases] poniżej (z towarzyszącymi problemami w repozytorium robertdebock):

* Rola sama w sobie powinna wstępnie załadować pamięć podręczną menedżera pakietów:
  https://github.com/robertdebock/ansible-role-bootstrap/pull/57[robertdebock/ansible-role-bootstrap#57]
  (naprawiona w
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/43[JonasPammer#43];
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/50[JonasPammer#50]
  )
* zmiana domyślnej wartości become na `false`, dodanie możliwości definiowania `become_user` oddzielnie od `ansible_user`:
  https://github.com/robertdebock/ansible-role-bootstrap/issues/63[robertdebock/ansible-role-bootstrap#63]
  (naprawiona w
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/61[JonasPammer#61]
  )
* zmiana domyślnej wartości `bootstrap_become_user` na root
* użycie `bootstrap_become_user` również w krokach modułów ansible
* kompatybilność roli z podman poprzez określenie `/bin/sh`
  https://github.com/robertdebock/ansible-role-bootstrap/pull/66[robertdebock/ansible-role-bootstrap#66]
  (naprawiona w
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/62[JonasPammer#62]
  )
=====

toc::[]

[[meta]]
== 🔎 Metadane
Poniżej możesz znaleźć informacje o…

* wymaganej wersji Ansible
* wspieranych platformach
* https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[zależnościach ról]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: bootstrap
  description: Rola Ansible do przygotowania systemu Linux do zarządzania przez Ansible. Oparta na roli robertdebocka.

  author: jonaspammer
  license: "MIT"

  min_ansible_version: "2.9"
  platforms:
    # uwaga: tekst po "aktywnie testowane: " to nazwa obrazu dockera
    - name: EL # (Enterprise Linux)
      versions:
        - "9" # aktywnie testowane: rockylinux9
    - name: Fedora
      versions:
        - "38" # aktywnie testowane: fedora38
        - "39" # aktywnie testowane: fedora39
    - name: Debian
      versions:
        - bullseye # aktywnie testowane: debian11
        - bookworm # aktywnie testowane: debian12
    - name: Ubuntu
      versions:
        - focal # aktywnie testowane: ubuntu2004
        - jammy # aktywnie testowane: ubuntu2204

  galaxy_tags:
    - bootstrap
    - python
    - sudo

dependencies: []
----


[[requirements]]
== 📌 Wymagania
// Wszelkie wymagania, które mogą nie być objęte tą rolą lub samym Ansible, powinny być tutaj wymienione.
Użytkownik Ansible musi mieć możliwość `become`.

[[variables]]
== 📜 Zmienne roli
// Opis zmiennych, które można ustawić dla tej roli, powinien być tutaj.
// oraz wszelkie zmienne, które mogą powinny być ustawienie za pomocą parametrów roli.
// Wszelkie zmienne odczytywane z innych ról i/lub globalnego zakresu (tj. hostvars, group vars, itp.)
// powinny być również tutaj wymienione.

[source,yaml]
----
bootstrap_user: root
----
https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#term-ansible_user[Nazwa użytkownika]
 używana do połączenia z maszyną dla głównych zadań `raw` związanych z _zbieraniem prostych faktów_ / _instalowaniem_.

[source,yaml]
----
bootstrap_become: false
bootstrap_become_user: root
----
Zmienna `become` i `become_user` przekazywane do większości rzeczywistych zadań.

Domyślna wartość dla `bootstrap_become` została ustawiona na `false`
z powodu założenia, że `sudo` nie jest dostępne
przed bootstrapowaniem.

[source,yaml]
----
bootstrap_wait_for_host: false
----
Czy czekać na dostępność hosta na `ansible_port` (22).

[source,yaml]
----
bootstrap_timeout: 3
----
Maksymalna liczba sekund czekania na zdalny system, aby stał się osiągalny/użyteczny, zanim wystąpi błąd.


[[public_vars]]
== 📜 Fakty/Zmienne zdefiniowane przez tę rolę

Każda zmienna wymieniona w tej sekcji
jest dynamicznie definiowana podczas wykonywania tej roli (i może być zastąpiona tylko za pomocą `ansible.builtin.set_facts`) _i_
jest przeznaczona do używania nie tylko wewnętrznie.


[[tags]]
== 🏷️ Tagi

// Zobacz https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// dla doskonałego przykładu grupowania zadań za pomocą tagów

Zadania są oznaczone następującymi
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[tagami]:

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

2+| Ta rola nie ma jeszcze oficjalnie udokumentowanych tagów.

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

Możesz używać Ansible do pomijania zadań lub uruchamiania tylko niektórych zadań za pomocą tych tagów. Domyślnie wszystkie zadania są uruchamiane, gdy nie są określone żadne tagi.

[[dependencies]]
== 👫 Zależności
// Lista innych ról powinna być tutaj,
// plus wszelkie szczegóły dotyczące parametrów, które mogą być ustawione dla innych ról,
// lub zmiennych używanych w innych rolach.


[[example_playbooks]]
== 📚 Przykładowe użycia plików playbooków
// Uwzględnienie przykładów, jak używać tej roli w playbooku dla typowych scenariuszy, jest zawsze miłe dla użytkowników:

[WAŻNE]
====
Musisz wyłączyć właściwość `gather_facts` w grze, w której używana jest ta rola.
Jeśli ta rola zakończy się sukcesem, sama wywoła https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html[
moduł setup Ansible] (co dałoby efekt równoważny, jaki dałby `gather_facts: true`).

Żadne zadania nie mogą być przed tą rolą.
====

.Najmniejsza wykonalna gra
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrapowanie maszyn linux do zarządzania przez Ansible.
  become: false
  gather_facts: false

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

.Zmiana użytkownika bootstrap (np. gdy root nie jest opcją)
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrapowanie maszyn linux do zarządzania przez Ansible.
  become: false
  gather_facts: false

  vars:
    bootstrap_user: "{{ ansible_user }}"

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


.Używając become true (np. gdy wiesz, że przynajmniej możesz używać sudo)
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrapowanie maszyn linux do zarządzania przez Ansible.
  become: true
  gather_facts: false

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

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


[[tested-distributions]]
== 🧪 Testowane dystrybucje

Rola może działać na różnych *dystrybucjach*, takich jak Red Hat Enterprise Linux (RHEL),
nawet jeśli nie ma testu dla tej konkretnej dystrybucji.

// dobra referencja do czego się trzymać -- większość projektów geerlingguy z gwiazdkami:
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Rodzina OS | Dystrybucja | Data wydania dystrybucji | Data zakończenia życia dystrybucji | Towarzyszący obraz dockera

// https://endoflife.date/rocky-linux
| Rocky
| Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 przebrany])
| 2021-06
| 2029-05
| https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[obraz: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[obraz:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

// https://endoflife.date/fedora (13 miesięcy)
| RedHat
| Fedora 39
| 2023-11
| 2024-12
| https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[obraz: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[obraz: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[obraz: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[obraz: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[obraz:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]]
|===


[[tested-ansible-versions]]
== 🧪 Testowane wersje Ansible

Testowane wersje Ansible starają się pozostawać zgodne ze wzorem wsparcia
https://github.com/ansible-collections/community.general#tested-with-ansible[
zbioru `community.general` Ansible].
W momencie pisania to:

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


[[development]]
== 📝 Rozwój
// Odznaki dotyczące Konwencji w tym Projekcie
https://conventionalcommits.org[obraz:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Konwencjonalne Commity]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-bootstrap/master[obraz:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-bootstrap/master.svg[status pre-commit]]
// obraz: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]]
=== 📌 Wymagania dotyczące maszyny deweloperskiej

* Python 3.10 lub wyższy
* Docker

[[development-dependencies]]
=== 📌 Wymagania dotyczące rozwoju
Wymagania rozwoju są definiowane w pliku
https://pip.pypa.io/en/stable/user_guide/#requirements-files[requirements-dev.txt].
Przykładowe instrukcje instalacji dla systemu Linux są pokazane poniżej:

----
# "opcjonalne": stwórz wirtualne środowisko python i aktywuj je dla bieżącej sesji shell
$ python3 -m venv venv
$ source venv/bin/activate

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

[[development-guidelines]]
=== ℹ️ Wytyczne dotyczące rozwoju ról Ansible

Proszę zapoznać się z moimi https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Wytycznymi dotyczącymi Rozwoju Ról Ansible].

Jeśli jesteś zainteresowany, zapisałem również kilka
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Ogólnych Wytycznych Dotyczących Rozwoju Ról Ansible (Najlepsze Praktyki)].

[[versioning]]
=== 🔢 Wersjonowanie

Wersje są definiowane za pomocą https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tagów],
które są https://galaxy.ansible.com/docs/contributing/version.html[uznawane i używane] przez Ansible Galaxy.

*Wersje nie mogą zaczynać się od `v`.*

Gdy nowy tag zostanie wprowadzony, https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml[
workflow CI GitHub]
(obraz:https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml/badge.svg[CI Wydania])
zajmuje się importowaniem roli na moje konto w Ansible Galaxy.

[[testing]]
=== 🧪 Testowanie
Automatyczne testy są uruchamiane przy każdym wkładzie za pomocą Workflow GitHub.

Testy dotyczą głównie uruchamiania https://molecule.readthedocs.io/en/latest/[Molecule]
na <<tested-distributions,różnych zestawach dystrybucji linuxowych>>
i używaniu <<tested-ansible-versions,various ansible versions>>.

Test molekularny zawiera również krok, który sprawdza wszystkie playbooki ansible za pomocą
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
w celu sprawdzenia najlepszych praktyk i zachowania, które może być potencjalnie poprawione.

Aby uruchomić testy, po prostu uruchom `tox` w wierszu poleceń.
Możesz przekazać opcjonalną zmienną środowiskową, aby zdefiniować dystrybucję kontenera Dockera, który zostanie uruchomiony przez molekuły:

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

Aby uzyskać listę możliwych wartości przekazywanych do `MOLECULE_DISTRO`,
zobacz macierz zdefiniowaną w link:.github/workflows/ci.yml[].

==== 🐛 Debugowanie kontenera Molecule

1. Uruchom testy molekularne z opcją `MOLECULE_DESTROY=never`, np.:
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TASK [ansible-role-pip : (wykonane).] pass:[************************]
  failed: [instance-py3-ansible-9] => changed=false
...
 pass:[___________________________________ podsumowanie ____________________________________]
  pre-commit: polecenia zakończone sukcesem
ERROR:   py3-ansible-9: polecenia nie powiodły się
----

2. Znajdź nazwę kontenera Dockera utworzonego przez molekuły:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   8 minut temu   Uruchomiono 8 minut                                                                                                    instance-py3-ansible-9
----

3. Wejdź do powłoki bash kontenera i wykonaj debugowanie:
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*

root@instance-py3-ansible-2:/#
----
+
[WSKAZÓWKA]
====
Jeśli awaria, którą próbujesz debugować, jest częścią kroku `verify.yml`, a nie `converge.yml`,
możesz chcieć wiedzieć, że wyniki modułów ansible (`vars`), hostów (`hostvars`) i
zmiennych środowiskowych zostały zapisane do plików zarówno na dostawcy, jak i wewnątrz maszyny dockera pod:

* `/var/tmp/vars.yml` (zawiera zmienne hostów pod kluczem `hostvars`)
* `/var/tmp/environment.yml`

`grep`, `cat` lub przekaż je wedle uznania!
====
+
[WSKAZÓWKA]
=====
Możesz również chcieć wiedzieć, że pliki wymienione w powyższym ostrzeżeniu
są dołączane do *Artefaktów CI GitHub* danego uruchomienia Workflow.
Dzięki temu można sprawdzić różnice między uruchomieniami
i pomóc w debugowaniu, co spowodowało uszkodzenie lub awarię w ogóle.

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

4. Po zakończeniu debugowania, wyjdź i zniszcz kontener:
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*

$ *docker stop #30e9b8d59cdf#*

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

==== 🐛 Debugowanie wersji pakietów zainstalowanych lokalnie

Chociaż jest to standardowa funkcja w tox 3, to https://github.com/tox-dev/tox/pull/2794[teraz] ma miejsce tylko wtedy, gdy tox rozpozna obecność zmiennej CI.
Na przykład:

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

[[development-container-extra]]
=== 🧃 WSKAZÓWKA: Idealne środowisko do rozwoju w kontenerze

Projekt ten oferuje definicję "Środowiska do Rozwoju w Kontenerze za 1 Kliknięciem".

Ten kontener pozwala nawet uruchamiać kontenery dockerowe w jego wnętrzu (Docker-In-Docker, dind),
umożliwiając wykonanie molekuły.

Aby go użyć:

1. Upewnij się, że spełniasz link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   wymagania systemowe kontenerów do rozwoju Visual Studio Code],
   opcjonalnie wykonując sekcję __Instalacja__ z podlinkowanej strony. +
   Obejmuje to: instalację Docker, instalację samego Visual Studio Code i instalację niezbędnego rozszerzenia.
2. Sklonuj projekt na swoją maszynę
3. Otwórz folder repozytoriów w Visual Studio Code (_Plik - Otwórz folder..._).
4. Jeśli otrzymasz komunikat w dolnym prawym rogu informujący o obecności definicji devcontainer,
możesz nacisnąć towarzyszący przycisk, aby w niego wejść.
*W przeciwnym razie,* możesz również wykonać polecenie Visual Studio `Remote-Containers: Open Folder in Container` samodzielnie (_Widok - Paleta poleceń_ -> _wpisz wspomniane polecenie_).

[WSKAZÓWKA]
====
Zalecam użycie `Remote-Containers: Rebuild Without Cache and Reopen in Container`
od czasu do czasu, ponieważ funkcja devcontainer ma czasami problemy z poprawnym rozpoznawaniem
wprowadzonych zmian w jego definicji.
====

[NOTA]
=====
Możesz potrzebować skonfigurować swój system gospodarza, aby umożliwić kontenerowi korzystanie z twoich kluczy SSH/GPG.

Procedura opisana jest https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
w oficjalnej dokumentacji devcontainer w sekcji "Udostępnianie poświadczeń GIT z twoim kontenerem"].
=====


[[cookiecutter]]
=== 🍪 CookieCutter

Niniejszy projekt należy utrzymywać w synchronizacji z
https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, z którego pierwotnie został ztemplowany]
przy użyciu https://github.com/cruft/cruft[cruft] (jeśli to możliwe) lub ręcznych zmian (jeśli konieczne)
na najlepszym możliwym poziomie.

.Oficjalne przykłady użycia `cruft update`
____
obraz::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Oficjalne przykłady użycia `cruft update`]
____

==== 🕗 Dziennik zmian
Gdy nowy tag zostanie wprowadzony, odpowiedni GitHub Release zostanie utworzony
przez Opiekuna Repozytorium, aby dostarczyć odpowiedni dziennik zmian z tytułem i opisem.


[[pre-commit]]
=== ℹ️ Ogólne konwencje dotyczące lintingu i stylu
Ogólne konwencje dotyczące lintingu i stylu
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*są automatycznie* przestrzegane zgodnie z zasadami]
przez różne https://pre-commit.com/[haczyki `pre-commit`], przynajmniej w pewnym zakresie.

Automatyczne uruchamianie pre-commit odbywa się przy każdym wkładzie za pomocą
https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Prośby o scalenie są automatycznie naprawiane przez to samo narzędzie,
przynajmniej przez haki, które automatycznie zmieniają pliki.

[NOTA]
====
Nie mylić:
Choć niektóre haki pre-commit mogą być w stanie ostrzec cię o błędach analizy składniowej w skryptach, a nawet w kodzie,
pre-commit sam w sobie nie uruchamia żadnych prawdziwych zestawów testowych.
Aby uzyskać informacje na temat testowania, zobacz <<testing>>.
====

[WSKAZÓWKA]
====
[[note_pre-commit-ci]]
Zalecam jednak zintegrować pre-commit do własnego lokalnego przepływu rozwoju.

Można to zrobić przez przejście do katalogu sklonowanego projektu i uruchomienie `pre-commit install`.
Dzięki temu Git będzie uruchamiał sprawdzania pre-commit przy każdym twoim commicie,
przerywając commit, jeśli jakiś hak wywoła alarm.

Możesz również, na przykład, wykonać haki pre-commit w dowolnym momencie, uruchamiając `pre-commit run --all-files`.
====


== 💪 Contributing
https://open.vscode.dev/jonaspammer/ansible-role-bootstrap[obraz:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Otwórz%20w%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Otwórz w Visual Studio Code]]
obraz:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs mile widziane]

// W zestawieniu z README.adoc
:toc:
:toclevels: 3

Poniższe sekcje mają charakter ogólny i służą do pomocy nowym współpracownikom.
Faktyczna "Dokumentacja dotycząca Rozwoju" tego projektu znajduje się w <<development>>.

=== Wstęp
Przede wszystkim dziękuję za rozważenie wniesienia wkładu do tego projektu.

Przestrzeganie tych wytycznych pomaga komunikować, że szanujesz czas deweloperów zarządzających i rozwijających ten projekt open source.
W zamian powinni oni wzajemnie szanować się, zajmując się twoim problemem, oceniając zmiany i pomagając ci sfinalizować twoje prośby o scalenie.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Ten projekt nadaje wiele swoich plików
https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, z którego pierwotnie został ztemplowany].

Proszę sprawdzić, czy edycja, którą masz na myśli, jest rzeczywiście stosowna do szablonu
i jeśli tak, zrób w nim odpowiednią zmianę.
Twoja zmiana może być również częściowo odpowiednia dla szablonu
jak i częściowo coś specyficznego dla tego projektu,
w takim przypadku stworzysz wiele PR.

=== 💬 Konwencjonalne Commity

Zwykły współpracownik nie musi się martwić przestrzeganiem
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__specyfikacji__]
https://www.conventionalcommits.org/en/v1.0.0/[__z definicji__],
ponieważ prośby o scalenie są łączone w jeden commit w projekcie.
Tylko główni współpracownicy, tj. ci, którzy mają prawa do wypychania do gałęzi projektu, muszą tego przestrzegać
(np. aby automatyczna detekcja wersji i generowanie dziennika zmian działały).

=== 🚀 Jak zacząć

Wkłady są składane do tego repozytorium za pomocą problemów i próśb o scaleni (PR).
Kilka ogólnych wskazówek obejmuje zarówno:

* Wyszukaj istniejące problemy i PR przed utworzeniem własnego.
* Jeśli nigdy wcześniej nie wnosiłeś wkładu, zapoznaj się z https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  przewodnikiem dla początkujących na blogu Auth0] po zasoby i porady, jak się za to zabrać.

==== Problemy

Problemy powinny być używane do zgłaszania problemów, proszenia o nową funkcję lub do omówienia potencjalnych zmian *przed* utworzeniem PR.
Kiedy https://github.com/JonasPammer/ansible-role-bootstrap/issues/new[
utworzysz nowy problem], załadowany zostanie szablon, który poprowadzi cię przez zbieranie i dostarczanie informacji, które potrzebujemy, aby zbadać.

Jeśli znajdziesz problem, który dotyczy twojego problemu,
dodaj swoje informacje dotyczące powtórzenia do istniejącego problemu *zamiast tworzyć nowy*.
Dodanie https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[reakcji]
może również pomóc wskazać naszym opiekunom, że dany problem dotyka więcej niż tylko zgłaszającego.

==== Prośby o scaleni

PR do tego projektu są zawsze mile widziane i mogą być szybkim sposobem na załatwienie twojej poprawki lub ulepszenia w kolejnym wydaniu.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[Ogólnie rzecz biorąc], PR powinny:

* Naprawiać lub dodawać funkcjonalność z panującym problemem *OR* zajmować się ogólnymi problemami białych miejsc/ stylu, nie obiema.
* Dodawać testy jednostkowe lub integracyjne dla naprawionej lub zmienionej funkcjonalności (jeśli już istnieje zestaw testowy).
* *Rozwiązywać pojedynczą obawę*
* *Znajdować dokumentację* w repozytorium
* Być towarzyszone pełnym szablonem prośby o scaleni (załadowanym automatycznie przy tworzeniu PR).

Dla zmian dotyczących podstawowej funkcjonalności lub które wymagałyby zmian przełomowych (np. główne wydanie)
najlepiej najpierw otworzyć problem, aby omówić swoją propozycję.

Ogólnie przestrzegamy pracy opartej na "fork-and-pull" w Git

1. Forkuj repozytorium do swojego konta Github
2. Sklonuj projekt na swoją maszynę
3. Utwórz lokalnie gałąź z zwięzłą, ale opisową nazwą
4. Zatwierdź zmiany do gałęzi
5. Przestrzegaj jakichkolwiek zasad dotyczących formatowania i testowania specyficznych dla tego repozytorium
6. Wypchnij zmiany do swojego forka
7. Otwórz PR w naszym repozytorium i wypełnij szablon PR, abyśmy mogli efektywnie przeglądać zmiany.


[[changelog]]
== 🗒 Zmiany
Proszę odwołać się do
https://github.com/JonasPammer/ansible-role-bootstrap/releases[Strona Wydań tego Repozytorium]
dla ludzkiego dziennika zmian odpowiadającego
https://github.com/JonasPammer/ansible-role-bootstrap/tags[Tagom (Wersją) tego Projektu].

Zauważ, że ten projekt przestrzega zasady wersjonowania semantycznego.
Proszę zgłaszać wszelkie przypadkowe zmiany przełomowe aktualizacji wersji mniejszej.


== ⚖️ Licencja

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

Copyright (c) 2022, Jonas Pammer

Niniejszym udziela się zezwolenia, bez opłat, każdej osobie, która uzyska kopię
tego oprogramowania i odpowiedniej dokumentacji (dalej "Oprogramowanie"), na korzystanie
z Oprogramowania bez żadnych ograniczeń, w tym bez ograniczeń w zakresie prawa
do używania, kopiowania, modyfikowania, łączenia, publikowania, dystrybucji, sublicencjonowania i/lub sprzedaży
kopii Oprogramowania oraz pozwala na czynienie tak przez osoby, którym Oprogramowanie
zostało dostarczone, z zastrzeżeniem następujących warunków:

Powyższa notka o prawach autorskich oraz niniejsza nota o zezwoleniu powinny być dołączone do wszelkich
kopii lub znaczących części Oprogramowania.

OPROGRAMOWANIE JEST DOSTARCZANE "TAK JAK JEST", BEZ GWARANCJI JAKIEGOKOLWIEK RODZAJU, WYRAŹNEJ LUB
IMPLICITNEJ, W TYM, ALE NIE OGRANICZAJĄC SIĘ DO GWARANCJI PRZYDATNOŚCI HANDLOWEJ,
PRZYDATNOŚCI DO OKREŚLONEGO CELU ORAZ BRAKU NARUSZENIA. W ŻADNYM WYPADKU ANI AUTORZY ANI POSIADACZE PRAW AUTORSKICH NIE BĘDĄ ODPOWIEDZIALNI ZA ŻADNE ROZKAZY, SZKODY LUB INNE
ODPOWIEDZIALNOŚCI, CZY TO W DZIAŁANIACH KONTRAKTOWYCH, CZY W DELIKCIE CZY INNYM, POWSTAŁE W
ZWIĄZKU Z OPROGRAMOWANIEM LUB KORZYSTANIEM LUB INNYMI TRANSAKCJAMI W OPROGRAMOWANIU.
----

Mam nadzieję, że tłumaczenie jest zrozumiałe! Jeśli potrzebujesz jakichkolwiek poprawek lub dodatkowych informacji, daj mi znać.