jonaspammer.core_dependencies

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

https://galaxy.ansible.com/jonaspammer/core_dependencies[obraz:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.core_dependencies-brightgreen[Wersja na Galaxy]]
// Bardzo Ważne Statusy
https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml[obraz:https://github.com/JonasPammer/ansible-role_core_dependencies/actions/workflows/ci.yml/badge.svg[Testowanie CI]]

Jest to rola Ansible do instalacji niezbędnych pakietów systemowych,
wymaganych do prawidłowego działania różnych modułów rdzeniowych Ansible, takich jak:

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

Ta rola także zapewnia aktualny cache pakietów dla większości systemów.

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

[UWAGA]
.DYSKLEJMER
=====
Ta rola jest pochodną https://github.com/robertdebock/ansible-role-core_dependencies/releases/tag/2.1.9[robertdebock/ansible-role-core_dependencies v2.1.9 na GitHubie (11 lutego 2022)] (https://github.com/robertdebock/ansible-role-core_dependencies/compare/2.1.9...master[porównaj zmiany odtąd])
(licencja Apache 2.0, prawa autorskie Robert de Bock ([email protected])),
na razie tylko z dodanymi komentarzami do kodu.
=====

toc::[]

[[meta]]
== 🔎 Metadane
Poniżej znajdziesz informacje na temat…

* wymaganą wersję Ansible dla tej roli
* wspierane platformy
* https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[dependencje roli]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: "core_dependencies"
  description:
    "Rola Ansible do instalacji zależności wspierających moduły rdzeniowe Ansible.
    Oparta na roli core_dependencies roberta de Bocka."

  author: "jonaspammer"
  license: "MIT"

  min_ansible_version: "2.11"
  platforms:
    - 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: []

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

Kolekcja https://galaxy.ansible.com/community/general[`community.general`]
musi być zainstalowana na kontrolerze Ansible.

[[variables]]
== 📜 Zmienne Roli
// Tutaj powinna się znaleźć opis zmiennych, które można ustawić dla tej roli
// oraz wszelkich zmiennych, które mogą powinny być ustawione za pomocą parametrów do roli.
// Jakiekolwiek zmienne odczytywane z innych ról i/lub globalnego zakresu (tj. hostvars, group vars itd.)
// powinny być tu również wymienione.

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

Każda zmienna wymieniona w tej sekcji
jest dynamicznie definiowana podczas wykonywania tej roli (i może być nadpisana tylko przy użyciu `ansible.builtin.set_facts`) _i_
jest przeznaczona do użycia nie tylko wewnętrznie.

[[tags]]
== 🏷️ Tagowanie

// Zobacz https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// jako doskonały przykład 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ć tagów w Ansible, aby pominąć zadania lub uruchomić tylko niektóre z nich. Domyślnie, wszystkie zadania są uruchamiane, gdy nie wskazano żadnych tagów.

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

[[example_playbooks]]
== 📚 Przykłady użycia playbooków
// Zawieranie przykładów użycia tej roli w playbooku dla typowych sytuacji jest zawsze miłe dla użytkowników.

[UWAGA]
====
Ta rola jest częścią https://github.com/JonasPammer/ansible-roles[
mojej licznej zbiorów ról do różnych zastosowań].

Maszyna musi być przygotowana.
W CI, robi się to w `molecule/resources/prepare.yml`
który czerpie swoje zależności z `requirements.yml`:

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

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

Poniższy diagram jest kompilacją "miękkich zależności" tej roli
oraz rekurencyjnego drzewa ich miękkich zależności.

obraz:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_core_dependencies.svg[
wykres zależności requirements.yml jonaspammer.core_dependencies]
====

.Minimum Viable Play
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrap linux machines to be managed by Ansible.
  gather_facts: false

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

.Bardziej Powszechne Zdarzenie
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Bootstrap linux machines to be managed by 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]]
== 🧪 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.

// dobrym odniesieniem do naśladowania są najbardziej gwiazdkowe i przypięte projekty geerlingguy:
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Rodzina OS | Dystrybucja | Data wydania dystrybucji | Data zakończenia wsparcia | 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 w przebraniu])
| 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]]

| 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ę być zgodne z
https://github.com/ansible-collections/community.general#tested-with-ansible[
wzorem wsparcia kolekcji `community.general` Ansible].
Aktualnie jest 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[Conventional Commits]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-core_dependencies/master[obraz:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-core_dependencies/master.svg[status pre-commit.ci]]
// 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]]
=== 📌 Zależności Środowiska Deweloperskiego

* Python 3.10 lub wyższy
* Docker

[[development-dependencies]]
=== 📌 Zależności Rozwojowe
Zależności rozwojowe są definiowane w 
https://pip.pypa.io/en/stable/user_guide/#requirements-files[plikach wymagań pip]
nazywanych `requirements-dev.txt`.
Przykłady instrukcji instalacji dla systemu Linux prezentują się następująco:

----
# "opcjonalne": stwórz wirtualne środowisko python i aktywuj je dla bieżącej sesji powłoki
$ 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, napisałem także o
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Ogólnych praktykach rozwoju ról Ansible (Najlepsze Praktyki)].

[[versioning]]
=== 🔢 Wersjonowanie

Wersje są definiowane za pomocą https://git-scm.com/book/en/v2/Git-Basics-Tagging[znaczników],
które z kolei 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 znacznik jest publikowany, https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml[
workflow CI GitHub]
(obraz:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml/badge.svg[CI wydania])
zajmuje się importowaniem roli na moje konto Ansible Galaxy.

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

Testy koncentrują się głównie na uruchamianiu https://molecule.readthedocs.io/en/latest/[Molecule]
na <<tested-distributions,zróżnicowanym zestawie dystrybucji linuxowych>>
i używaniu <<tested-ansible-versions,różnych wersji ansible>>.

Testy Molecule obejmują także kroki, które linterują wszystkie playbooki Ansible za pomocą
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
aby sprawdzić najlepsze praktyki oraz sposób działania, który mógłby zostać polepszony.

Aby uruchomić testy, wystarczy wykonać `tox` w wierszu poleceń.
Możesz przekazać opcjonalną zmienną środowiskową, aby zdefiniować dystrybucję kontenera Docker, który będzie uruchamiany przez Molecule:

----
$ 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 swoje testy Molecule z opcją `MOLECULE_DESTROY=never`, np.:
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TASK [ansible-role-pip : (znaczenie usunięte).] pass:[************************]
  failed: [instance-py3-ansible-9] => changed=false
...
 pass:[___________________________________ podsumowanie ____________________________________]
  pre-commit: polecenia powiodły się
ERROR:   py3-ansible-9: polecenia nie powiodły się
----

2. Znajdź nazwę kontenera Docker utworzonego przez Molecule:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   8 minut temu   Włączony przez 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:/#
----
+
[TIP]
====
Jeśli błąd, który próbujesz zdebugować, jest częścią kroku `verify.yml`, a nie `converge.yml`,
możesz chcieć wiedzieć, że wyniki modułów Ansible (`vars`), hosty (`hostvars`) i
zmienne środowiskowe zostały zapisane w plikach na obu maszynie przygotowującej i w kontenerze docker pod:
* `/var/tmp/vars.yml` (zawiera zmienne hostów pod kluczem `hostvars`)
* `/var/tmp/environment.yml`
`grep`, `cat` lub przenieś te pliki według potrzeb!
====
+
[TIP]
=====
Możesz również chcieć wiedzieć, że pliki wymienione w powyższej wskazówce
są załączone do *Artefaktów CI GitHub* danego przebiegu. +
Umożliwia to sprawdzenie różnic między przebiegami,
co pomaga w debugowaniu, co spowodowało erozję lub błędy 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 zainstalowanych pakietów lokalnie

Mimo że to standardowa funkcja w tox 3, to https://github.com/tox-dev/tox/pull/2794[teraz] dzieje się to tylko wtedy, gdy tox rozpozna obecność zmiennej CI.
Na przykład:

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

[[development-container-extra]]
=== 🧃 TIP: Idealne Środowisko Deweloperskie w Kontenerze

Ten projekt oferuje definicję "środowiska deweloperskiego w kontenerze z jednym kliknięciem".

Ten kontener umożliwia nawet uruchamianie kontenerów Docker w jego wnętrzu (Docker-in-Docker, dind),
co pozwala na wykonanie Molecule.

Aby z niego skorzystać:

1. Upewnij się, że spełniasz link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   wymagania systemowe kontenerów deweloperskich Visual Studio Code],
   opcjonalnie postępując zgodnie z sekcją __Instalacja__ odnośnej strony. +
   Obejmuje to: Instalację Dockera, instalację samego Visual Studio Code i zainstalowanie odpowiedniego rozszerzenia.
2. Sklonuj projekt na swoją maszynę
3. Otwórz folder repozytorium w Visual Studio Code (_Plik - Otwórz folder…_).
4. Jeśli pojawi się monit w prawym dolnym rogu informujący o obecności definicji devcontainer,
możesz nacisnąć towarzyszący przycisk, aby do niego wejść.
*W przeciwnym razie,* możesz również wykonać polecenie Visual Studio „Remote-Containers: Otwórz folder w kontenerze” samodzielnie (_Widok - Paleta poleceń_ -> _wpisz wspomniane polecenie_).

[TIP]
====
Zalecam użycie „Remote-Containers: Przebuduj bez cache i ponownie otwórz w kontenerze”
od czasu do czasu, ponieważ funkcja devcontainer czasami ma problemy z rozpoznaniem
zmian wprowadzonych do jej definicji.
====

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

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

[[cookiecutter]]
=== 🍪 CookieCutter

Projekt ten powinien być na bieżąco synchronizowany z
https://github.com/JonasPammer/cookiecutter-ansible-role[CookieCutter, z którego został pierwotnie wygenerowany]
za pomocą https://github.com/cruft/cruft[cruft] (jeśli to możliwe) lub ręcznych zmian (jeśli zajdzie taka potrzeba)
w jak najlepszym stopniu.

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

==== 🕗 Dziennik zmian
Gdy nowy znacznik jest publikowany, odpowiedni GitHub Release zostanie utworzony
przez opiekuna repozytorium, aby dostarczyć odpowiedni ludzkim dziennik zmian z tytułem i opisem.

[[pre-commit]]
=== ℹ️ Ogólne zasady linijki i stylu
Ogólne zasady linijki i stylu
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*są automatycznie* utrzymywane w standardzie]
przez różne https://pre-commit.com/[`pre-commit`] haki, przynajmniej w pewnym stopniu.

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 zmiany są automatycznie naprawiane przez to narzędzie,
przynajmniej haki, które automatycznie zmieniają pliki.

[UWAGA]
====
Nie mylić:
Pomimo że niektóre haki pre-commit mogą być w stanie ostrzegać cię o błędach analizowanych przez skrypty w składni lub nawet kodzie w pewnym stopniu (dlatego haki pre-commit są *częścią* zestawu testów),
pre-commit sam w sobie nie uruchamia żadnych rzeczywistych zestawów testów.
Informacje na temat testowania znajdziesz w <<testing>>.
====

[TIP]
====
[[note_pre-commit-ci]]
Zalecam jednak zintegrowanie pre-commit w swoją lokalną pracę deweloperską osobiście.

Można to zrobić, wchodząc do katalogu lokalnego sklonowanego projektu i uruchamiając `pre-commit install`.
Pozwoli to gitowi na uruchomienie kontroli pre-commit przy każdym commicie, 
przerywając same commity, jeśli jakiś hak alarmuje.

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

[[contributing]]
== 💪 Wkład
https://open.vscode.dev/JonasPammer/ansible-role-core_dependencies[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[Wkład PR]

// Zawarte w README.adoc
:toc:
:toclevels: 3

Poniższe sekcje mają charakter ogólny i są używane do pomocy nowym współpracownikom.
Fakt, że „Dokumentacja rozwoju” tego projektu znajduje się w sekcji <<development>>.

=== 🤝 Preambuła
Przede wszystkim dziękuję za rozważenie wniesienia wkładu do tego projektu.

Podążanie za tymi wytycznymi pomaga przekazać szacunek dla czasu deweloperów zarządzających i rozwijających ten projekt open source.
W zamian powinni oni odwzajemnić ten szacunek, zajmując się twoim problemem, oceniając zmiany i pomagając ci sfinalizować twoje prośby o zmiany.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Dzięki projektowi wiele z jego plików pochodzi z
https://github.com/JonasPammer/cookiecutter-ansible-role [CookieCutter, z którego został pierwotnie wygenerowany].

Proszę sprawdzić, czy edytowana zmiana, którą masz na myśli, jest rzeczywiście odpowiednia dla szablonu,
a jeśli tak, dokonaj odpowiedniej zmiany tam zamiast tego.
Twoja zmiana może być również częściowo odpowiednia dla szablonu
i częściowo dla czegoś konkretnego dla tego projektu,
w takim przypadku będziesz tworzyć wiele PR.

=== 💬 Konwencjonalne Commity

Zwykły współpracownik nie musi obawiać się przestrzegania
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__specyfikacji__]
https://www.conventionalcommits.org/en/v1.0.0/[__na mocy definicji__],
ponieważ prośby o zmiany są scalane w jeden commit w projekcie.
Tylko rdzeniowi współpracownicy, tj. ci, którzy mają prawa do wysyłania w gałęzie tego projektu, muszą się do nich stosować
(np. aby umożliwić automatyczne określenie wersji i generowanie dzienników zmian).

=== 🚀 Jak zacząć

Wkłady są dokonywane do tego repozytorium poprzez Problemy i Prośby o Zmiany (PR).
Kilka ogólnych wytycznych dotyczących obu:

* Przeszukaj istniejące Problemy i PR przed utworzeniem własnych.
* Jeśli nigdy wcześniej nie współpracowałeś, zobacz https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  przewodnik dla początkujących na blogu Auth0] po zasoby i wskazówki, jak zacząć.

==== Problemy

Problemy powinny być używane do zgłaszania problemów, żądania nowych funkcji lub omówienia potencjalnych zmian *przed* utworzeniem PR.
Gdy https://github.com/JonasPammer/ansible-role-core_dependencies/issues/new[
utworzysz nowy problem], załadowany zostanie szablon, który poprowadzi cię przez zbieranie i dostarczanie informacji, których potrzebujemy do dochodzenia.

Jeśli znajdziesz problem, który dotyczy problemu, z jakim się borykasz,
proszę dodaj swoje informacje o reprodukcji 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, wskazując naszym opiekunom, że dany problem dotyka więcej niż tylko zgłaszającego.

==== Prośby o Zmiany

PR w tym Projekcie są zawsze mile widziane i mogą być szybkim sposobem na uzyskanie naprawy lub ulepszenia zaplanowanego na następne wydanie.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[Ogólnie rzecz biorąc], PR powinny:

* Tylko naprawić/dodać funkcjonalność w danym zakresie *LUB* zająć się szeroką kwestią białych miejsc/styli, a nie obu.
* Dodać testy jednostkowe lub integracyjne dla naprawionej lub zmienionej funkcjonalności (jeśli zestaw testów już istnieje).
* *Odnosić się do jednego problemu*
* *Zawierać dokumentację* w repozytorium
* Być dostarczone z kompletnym szablonem Prośby o Zmianę (ładowanym automatycznie przy tworzeniu PR).

Dla zmian, które odnoszą się do podstawowej funkcjonalności lub wymagałyby zmian w wersji (np. dużego wydania),
najlepiej otworzyć Problem, aby najpierw omówić swój pomysł.

Ogólnie postępujemy zgodnie z "fork-and-pull" (rozgałęzienie i pobranie) metodą Git.

1. Rozgałęzić repozytorium do własnego konta Github
2. Sklonuj projekt na swoją maszynę
3. Stwórz lokalnie gałąź z krótką, ale opisową nazwą
4. Zatwierdź zmiany w gałęzi
5. Zgodnie z wszelkimi wskazówkami dotyczącymi formatowania i testowania specyficznymi dla tego repozytorium
6. Wyślij zmiany do swojego forka
7. Otwórz PR w naszym repozytorium i postępuj zgodnie z szablonem PR, abyśmy mogli efektywnie przejrzeć zmiany.

[[changelog]]
== 🗒 Dziennik zmian
Proszę odwołać się do 
https://github.com/JonasPammer/ansible-role-core_dependencies/releases[Strona wydania tego repozytorium]
po ludzki dziennik zmian odpowiedni do 
https://github.com/JonasPammer/ansible-role-core_dependencies/tags[Tagów (Wersji) tego projektu].

Zauważ, że ten Projekt przestrzega wersjonowania semantycznego.
Proszę zgłaszać wszelkie przypadkowe zmiany łamiące mniejsze aktualizacje wersji.

[[license]]
== ⚖️ Licencja

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

Copyright (c) 2022, Jonas Pammer

Przyznaje się niniejszym, bez opłat, każdej osobie uzyskującej kopię
tego oprogramowania oraz związanej z nim dokumentacji (zwanej dalej "Oprogramowaniem"), prawo do korzystania
z Oprogramowania bez ograniczeń, w tym bez ograniczeń do praw
do używania, kopiowania, modyfikowania, scalania, publikowania, dystrybuowania, sublicencjonowania oraz/lub sprzedaży
kopii Oprogramowania oraz do zezwalania osobom, którym Oprogramowanie jest udostępnione, na to,
pod warunkiem spełnienia poniższych warunków:

Powyższe ogłoszenie o prawach autorskich i niniejsze zezwolenie muszą być dołączone do wszystkich
kopii lub istotnych części Oprogramowania.

OPROGRAMOWANIE JEST DOSTARCZANE "TAK JAK JEST", BEZ ŻADNEJ GWARANCJI,
WYRAŹNEJ ANI DOMNIEMANEJ, W TYM, ALE NIE OGRANICZAJĄC SIĘ DO GWARANCJI
PRZYDATNOŚCI HANDLOWEJ, PRZYDATNOŚCI DO KONKRETNEGO CELU I NARUSZENIA PRAW.
W ŻADNYM WYPADKU AUTORZY LUB POSIADACZE PRAW AUTORSKICH NIE BĘDĄ ODPOWIADAĆ ZA ŻADNE ROSZCZENIA,
SZKODY LUB INNE ODPowiedzialności, CZY TO W DZIAŁANIU UMOWI, DELIKCIE LUB INNYM,
WYNIKAJĄCE Z, LUB W ZWIĄZKU Z OPROGRAMOWANIEM LUB UŻYTKOWANIEM CZY INNYMI TRANSAKCJAMI W OPROGRAMOWANIU.

----