jonaspammer.core_dependencies

// Este archivo está siendo generado por .github/workflows/gh-pages.yml - ¡todos los cambios locales se perderán eventualmente!
= ansible-role-core_dependencies
Jonas Pammer <[email protected]>;
:toc: izquierda
:toclevels: 2
:toc-placement!:
:source-highlighter: rouge

https://galaxy.ansible.com/jonaspammer/core_dependencies[imagen:https://img.shields.io/badge/ disponible%20en%20ansible%20galaxy-jonaspammer.core_dependencies-brightgreen[Versión en Galaxy]]
// Insignias de estado muy relevantes
https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml[imagen:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/ci.yml/badge.svg[Pruebas CI]]

Un rol de Ansible para instalar los paquetes de sistema necesarios
requeridos para la correcta ejecución de varios módulos centrales de Ansible, a saber:

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

Este rol también garantiza que haya un caché de paquetes actualizado para la mayoría de los sistemas.

En la mayoría de los casos, querrás usar este rol en combinación con mi
https://github.com/JonasPammer/ansible-role-bootstrap[`rol bootstrap`].

[NOTA]
.DESCLAIMER
=====
Este rol es un fork de https://github.com/robertdebock/ansible-role-core_dependencies/releases/tag/2.1.9[robertdebock/ansible-role-core_dependencies v2.1.9 en GitHub (11 Feb, 2022)] (https://github.com/robertdebock/ansible-role-core_dependencies/compare/2.1.9...master[comparar cambios desde aquí])
(Licencia Apache 2.0, Copyright Robert de Bock ([email protected])),
por ahora solo con comentarios de código añadidos.
=====

toc::[]

[[meta]]
== 🔎 Metadatos
A continuación puedes encontrar información sobre…

* la versión de Ansible requerida para el rol
* las plataformas soportadas por el rol
* las https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[dependencias del rol]

.link:meta/main.yml[]
[source,yaml]
----
---
galaxy_info:
  role_name: "core_dependencies"
  description:
    "Un rol de ansible para instalar dependencias que apoyan los módulos centrales de Ansible.
    Basado en el rol core_dependencies de robertdebock."

  author: "jonaspammer"
  license: "MIT"

  min_ansible_version: "2.11"
  platforms:
    # nota: el texto después de "probado activamente: " representa el nombre de la imagen de docker
    - name: EL # (Enterprise Linux)
      versions:
        - "9" # probado activamente: rockylinux9
    - name: Fedora
      versions:
        - "38" # probado activamente: fedora38
        - "39" # probado activamente: fedora39
    - name: Debian
      versions:
        - bullseye # probado activamente: debian11
        - bookworm # probado activamente: debian12
    - name: Ubuntu
      versions:
        - focal # probado activamente: ubuntu2004
        - jammy # probado activamente: ubuntu2204

  galaxy_tags: []

dependencies: []
----

[[requirements]]
== 📌 Requisitos
// Cualquier requisito previo que quizás no esté cubierto por este rol o por Ansible mismo debe mencionarse aquí.
El usuario de Ansible necesita poder `become`.

La colección https://galaxy.ansible.com/community/general[`community.general`]
debe estar instalada en el controlador de Ansible.

[[variables]]
== 📜 Variables del Rol
// Una descripción de las variables ajustables para este rol debe ir aquí
// y cualquier variable que se puede/debe configurar mediante parámetros al rol.
// Cualquier variable que se lea de otros roles y/o del ámbito global (es decir, hostvars, vars de grupo, etc.)
// también debe mencionarse aquí.

[[public_vars]]
== 📜 Hechos/Variables definidas por este rol

Cada variable listada en esta sección
se define dinámicamente cuando se ejecuta este rol (y solo se puede sobrescribir usando `ansible.builtin.set_facts`) _y_
se pretende que se use no solo internamente.

[[tags]]
== 🏷️ Etiquetas

// Consulta https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags
// para un increíble ejemplo de agrupación de tareas utilizando etiquetas

Las tareas están etiquetadas con las siguientes
https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[etiquetas]:

[cols="1,1"]
|===
|Etiqueta | Propósito

2+| Este rol aún no tiene etiquetas documentadas oficialmente.

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

Puedes usar Ansible para omitir tareas, o solo ejecutar ciertas tareas usando estas etiquetas. Por defecto, todas las tareas se ejecutan cuando no se especifican etiquetas.

[[dependencies]]
== 👫 Dependencias
// Una lista de otros roles debe ir aquí,
// más cualquier detalle con respecto a los parámetros que deben establecerse para otros roles,
// o variables que se usan de otros roles.

[[example_playbooks]]
== 📚 Ejemplos de Uso de Playbooks
// Incluir ejemplos de cómo usar este rol en un playbook para escenarios comunes siempre es útil para los usuarios.

[NOTA]
====
Este rol es parte de https://github.com/JonasPammer/ansible-roles[
muchos roles específicos compatibles de mi autoría].

La máquina necesita estar preparada.
En CI, esto se realiza en `molecule/resources/prepare.yml`
que obtiene sus dependencias suaves de `requirements.yml`:

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

  roles:
    - rol: jonaspammer.bootstrap
----

El siguiente diagrama es una compilación de las "dependencias suaves" de este rol
así como el árbol recursivo de sus dependencias suaves.

imagen:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_core_dependencies.svg[
gráfico de dependencias de requirements.yml de jonaspammer.core_dependencies]
====

.Mínimo Play Viable
====
[source,yaml]
-----
---
- hosts: servidores:&provisionados
  name: Preparar máquinas linux para ser administradas por Ansible.
  gather_facts: false

  roles:
    - rol: jonaspammer.core_dependencies
-----
====

.Juego Más Común
====
[source,yaml]
-----
---
- hosts: servidores:&provisionados
  name: Preparar máquinas linux para ser administradas por Ansible.
  become: false
  gather_facts: false

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


[[tested-distributions]]
== 🧪 Distribuciones Probadas

Un rol puede funcionar en diferentes *distribuciones*, como Red Hat Enterprise Linux (RHEL),
aunque no haya pruebas para esta distribución exacta.

// buena referencia para lo que se debe seguir -- el proyecto más estrellado y anclado de geerlingguy:
// https://github.com/geerlingguy/ansible-role-docker/blob/master/.github/workflows/ci.yml
|===
| Familia OS | Distribución | Fecha de Lanzamiento de la Distribución | Fin de Vida de la Distribución | Imagen de Docker Acompañante

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

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


[[tested-ansible-versions]]
== 🧪 Versiones de Ansible Probadas

Las versiones de ansible probadas intentan mantener equivalencia con el
https://github.com/ansible-collections/community.general#tested-with-ansible[
patrón de soporte de la colección `community.general` de Ansible].
A la fecha de redacción es:

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


[[development]]
== 📝 Desarrollo
// Insignias sobre convenciones en este Proyecto
https://conventionalcommits.org[imagen:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Commits Convencionales]]
https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-core_dependencies/master[imagen:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-core_dependencies/master.svg[estado pre-commit.ci]]
// imagen: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]]
=== 📌 Dependencias para el Sistema de Desarrollo

* Python 3.10 o superior
* Docker

[[development-dependencies]]
=== 📌 Dependencias de Desarrollo
Las Dependencias de Desarrollo están definidas en un
https://pip.pypa.io/en/stable/user_guide/#requirements-files[archivo de requisitos pip]
nombrado `requirements-dev.txt`.
A continuación se muestran instrucciones de instalación de ejemplo para Linux:

----
# "opcional": crea un entorno virtual de python y actívalo para la sesión actual del shell
$ python3 -m venv venv
$ source venv/bin/activate

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

[[development-guidelines]]
=== ℹ️ Directrices para el Desarrollo de Roles de Ansible

Por favor, consulta mis https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Directrices para el Desarrollo de Roles de Ansible].

Si te interesa, también he escrito algunas
https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[
Prácticas (Mejores) Generales para el Desarrollo de Roles de Ansible].

[[versioning]]
=== 🔢 Versionado

Las versiones se definen utilizando https://git-scm.com/book/en/v2/Git-Basics-Tagging[Etiquetas],
que a su vez son https://galaxy.ansible.com/docs/contributing/version.html[reconocidas y utilizadas] por Ansible Galaxy.

*Las versiones no deben comenzar con `v`.*

Cuando se empuja una nueva etiqueta, https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml[
un flujo de trabajo de CI en GitHub]
(imagen:https://github.com/JonasPammer/ansible-role-core_dependencies/actions/workflows/release-to-galaxy.yml/badge.svg[CI de Lanzamiento])
se encarga de importar el rol a mi cuenta de Ansible Galaxy.

[[testing]]
=== 🧪 Pruebas
Se realizan pruebas automáticas en cada contribución utilizando Flujos de Trabajo de GitHub.

Las pruebas se centran principalmente en ejecutar https://molecule.readthedocs.io/en/latest/[Molecule]
en un <<tested-distributions, conjunto variable de distribuciones de linux>>
y utilizando <<tested-ansible-versions,varias versiones de ansible>>.

La prueba de molecule también incluye un paso que revisa todos los playbooks de ansible usando
https://github.com/ansible/ansible-lint#readme[`ansible-lint`]
para verificar mejores prácticas y comportamientos que podrían mejorarse.

Para ejecutar las pruebas, simplemente ejecuta `tox` en la línea de comandos.
Puedes pasar una variable de entorno opcional para definir la distribución del
contenedor Docker que se iniciará con molecule:

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

Para una lista de posibles valores alimentados a `MOLECULE_DISTRO`,
mira la matriz definida en link:.github/workflows/ci.yml[].

==== 🐛 Depuración de un Contenedor de Molecule

1. Ejecuta tus pruebas de molecule con la opción `MOLECULE_DESTROY=never`, por ejemplo:
+
[subs="quotes,macros"]
----
$ *MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5#*
...
  TAREA [ansible-role-pip : (redactada).] pasa:[************************]
  falló: [instance-py3-ansible-9] => changed=false
...
 pasa:[___________________________________ resumen ____________________________________]
  pre-commit: comandos exitosos
ERROR:   py3-ansible-9: comandos fallaron
----

2. Averigua el nombre del contenedor de docker provisionado por molecule:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   hace 8 minutos   Arriba hace 8 minutos                                                                                                    instance-py3-ansible-9
----

3. Entra en una Shell de bash del contenedor y haz tu depuración:
+
[subs="quotes"]
----
$ *docker exec -it #30e9b8d59cdf# /bin/bash*

root@instance-py3-ansible-2:/#
----
+
[SUGERENCIA]
====
Si el fallo que intentas depurar es parte de tu paso `verify.yml` y no el `converge.yml` real,
puedes querer saber que la salida de los módulos de ansible (`vars`), hosts (`hostvars`) y
variables de entorno se han almacenado en archivos tanto en el provisionador como dentro de la máquina docker bajo:
* `/var/tmp/vars.yml` (contiene variables de host bajo la clave `hostvars`)
* `/var/tmp/environment.yml`
`grep`, `cat` o transfiere estos como desees.
====
+
[SUGERENCIA]
=====
También puedes querer saber que los archivos mencionados en la advertencia anterior
se adjuntan a los *Artefactos de CI de GitHub* de una ejecución de flujo de trabajo dada. +
Esto permite revisar la diferencia entre ejecuciones
y así ayudar en la depuración de lo que causó la degradación o fallo en general.

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

4. Después de haber terminado tu depuración, sal y destruye el contenedor:
+
[subs="quotes"]
----
root@instance-py3-ansible-2:/# *exit*

$ *docker stop #30e9b8d59cdf#*

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

==== 🐛 Depuración de versiones de paquetes instalados localmente

Aunque es una característica estándar en tox 3, esto https://github.com/tox-dev/tox/pull/2794[ahora] solo sucede cuando tox reconoce la presencia de una variable de CI.
Por ejemplo:

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


[[development-container-extra]]
=== 🧃 SUGERENCIA: Entorno de Desarrollo Ideal Contenerizado

Este Proyecto ofrece una definición para un "Entorno de Desarrollo Contenerizado con 1 Clic".

Este Contenedor incluso permite ejecutar contenedores de docker dentro de él (Docker-In-Docker, dind),
lo que permite la ejecución de molecule.

Para usarlo:

1. Asegúrate de cumplir con los link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[
   requisitos del sistema de los Contenedores de Desarrollo de Visual Studio Code],
   siguiendo opcionalmente la sección de __Instalación__ de la página enlazada. +
   Esto incluye: Instalación de Docker, Instalación de Visual Studio Code y la Instalación de la extensión necesaria.
2. Clona el proyecto en tu máquina
3. Abre la carpeta del repositorio en Visual Studio Code (_Archivo - Abrir Carpeta…_).
4. Si recibes un aviso en la esquina inferior derecha informándote sobre la presencia de la definición del devcontainer,
puedes presionar el botón correspondiente para entrar en ella.
*De lo contrario,* también puedes ejecutar el comando de Visual Studio `Remote-Containers: Open Folder in Container` tú mismo (_Ver - Paleta de Comandos_ -> _escribe el comando mencionado_).

[SUGERENCIA]
====
Recomiendo usar `Remote-Containers: Rebuild Without Cache and Reopen in Container`
de vez en cuando ya que la función del devcontainer tiene algunos problemas para reconocer
cambios realizados en su definición correctamente a veces.
====

[NOTA]
=====
Es posible que debas configurar tu sistema anfitrión para permitir que el contenedor use tus claves SSH/GPG.

El procedimiento se describe https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
en la documentación oficial de devcontainer bajo "Compartiendo credenciales de Git con tu contenedor"].
=====


[[cookiecutter]]
=== 🍪 CookieCutter

Este Proyecto debe mantenerse sincronizado con
https://github.com/JonasPammer/cookiecutter-ansible-role[el CookieCutter del que se templado originalmente]
utilizando https://github.com/cruft/cruft[cruft] (si es posible) o mediante alteración manual (si es necesario)
de la mejor manera posible.

.Ejemplo Oficial de Uso de `cruft update`
____
imagen::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Ejemplo Oficial de Uso de `cruft update`]
____

==== 🕗 Registro de Cambios
Cuando se empuja una nueva etiqueta, un correspondiente Lanzamiento de GitHub será creado
por el Mantenedor del Repositorio para proporcionar un adecuado registro de cambios humanos con un título y descripción.


[[pre-commit]]
=== ℹ️ Convenciones Generales de Linter y Estilo
Las Convenciones Generales de Linter y Estilo se
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*mantienen automáticamente* según los estándares]
por varios ganchos de https://pre-commit.com/[`pre-commit`], al menos hasta cierto punto.

La Ejecución Automática de pre-commit se realiza en cada Contribución utilizando
https://pre-commit.ci[`pre-commit.ci`]<<note_pre-commit-ci,*>>.
Las Solicitudes de Extracción incluso se corrigen automáticamente por la misma herramienta,
al menos por los ganchos que alteran automáticamente archivos.

[NOTA]
====
Para no confundir:
Aunque algunos ganchos de pre-commit pueden advertirte sobre fallos analizados por el script en la sintaxis o incluso en el código hasta cierto punto (por lo que los ganchos de pre-commit son *parte de* la suite de pruebas),
pre-commit en sí no ejecuta ninguna suite de pruebas real.
Para información sobre pruebas, consulta <<testing>>.
====

[SUGERENCIA]
====
[[note_pre-commit-ci]]
Sin embargo, te recomiendo que integres pre-commit en tu flujo de trabajo de desarrollo local por ti mismo.

Esto se puede hacer navegando al directorio de tu proyecto clonado y ejecutando `pre-commit install`.
Hacer esto hará que git ejecute verificaciones de pre-commit en cada commit que realices,
abortando los commits si se dispara una alarma de un gancho.

También puedes, por ejemplo, ejecutar los ganchos de pre-commit en cualquier momento ejecutando `pre-commit run --all-files`.
====


[[contributing]]
== 💪 Contribuyendo
https://open.vscode.dev/JonasPammer/ansible-role-core_dependencies[imagen:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Abrir en Visual Studio Code]]
imagen:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs Bienvenidas]

// Incluido en README.adoc
:toc:
:toclevels: 3

Las siguientes secciones son de naturaleza genérica y se utilizan para ayudar a nuevos contribuyentes.
La "Documentación de Desarrollo" real de este proyecto se encuentra en <<development>>.

=== 🤝 Preámbulo
Primero que nada, gracias por considerar contribuir a este Proyecto.

Seguir estas directrices ayuda a comunicar que respetas el tiempo de los desarrolladores que gestionan y desarrollan este proyecto de código abierto.
A cambio, ellos deben reciprocidad ese respeto al abordar tu problema, evaluar cambios y ayudarte a finalizar tus solicitudes de extracción.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Este Proyecto posee muchos de sus archivos de
https://github.com/JonasPammer/cookiecutter-ansible-role[el CookieCutter del que se templado originalmente].

Por favor, verifica si la edición que tienes en mente es realmente aplicable a la plantilla
y, si es así, haz un cambio apropiado allí en su lugar.
Tu cambio también puede ser aplicable parcialmente a la plantilla
así como parcialmente a algo específico de este proyecto,
en cuyo caso estarías creando múltiples PRs.

=== 💬 Commits Convencionales

Un contribuyente ocasional no tiene que preocuparse por seguir
https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__la especificación__]
https://www.conventionalcommits.org/en/v1.0.0/[__por definición__],
ya que las solicitudes de extracción se combinan en un solo commit en el proyecto.
Solo los contribuyentes principales, es decir, aquellos con derechos para hacer push a las ramas de este proyecto, deben seguirla
(por ejemplo, para permitir que la determinación automática de versiones y la generación de registros de cambios funcionen).

=== 🚀 Comenzando

Las contribuciones se realizan a este repositorio a través de Problemas y Solicitudes de Extracción (PRs).
Algunas pautas generales que cubren ambos:

* Busca Problemas y PRs existentes antes de crear el tuyo.
* Si nunca has contribuido antes, consulta https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[
  la guía para principiantes en el blog de Auth0] para obtener recursos y consejos sobre cómo comenzar.

==== Problemas

Los problemas deben usarse para informar problemas, solicitar una nueva funcionalidad, o discutir cambios potenciales *antes* de que se cree una PR.
Cuando https://github.com/JonasPammer/ansible-role-core_dependencies/issues/new[
creas un nuevo Problema], se cargará una plantilla que te guiará para recopilar y proporcionar la información que necesitamos para investigar.

Si encuentras un Problema que aborda el problema que estás teniendo,
por favor agrega tu propia información de reproducción al problema existente *en lugar de crear uno nuevo*.
Agregar una https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[reacción]
también puede ayudar a indicar a nuestros mantenedores que un problema particular afecta a más personas que solo al reportador.

==== Solicitudes de Extracción

Las PRs en este Proyecto siempre son bienvenidas y pueden ser una forma rápida de obtener tu arreglo o mejora programada para el próximo lanzamiento.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[En general], las PRs deben:

* Solo corregir/agregar la funcionalidad en cuestión *O* abordar problemas de estilo/espaciado generalizados, no ambas cosas.
* Agregar pruebas unitarias o de integración para la funcionalidad corregida o cambiada (si ya existe una suite de pruebas).
* *Abordar una sola preocupación*
* *Incluir documentación* en el repositorio
* Ser acompañadas por una plantilla de Solicitud de Extracción completa (cargada automáticamente cuando se crea una PR).

Para cambios que abordan funcionalidad central o que requerirían cambios drásticos (por ejemplo, un lanzamiento importante),
es mejor abrir un Problema para discutir tu propuesta primero.

En general, seguimos el flujo de trabajo de Git "fork-and-pull"

1. Haz un fork del repositorio a tu propia cuenta de Github
2. Clona el proyecto en tu máquina
3. Crea una rama localmente con un nombre breve pero descriptivo
4. Realiza cambios en la rama
5. Siguiendo cualquier guía de formato y prueba específica de este repositorio
6. Empuja cambios a tu fork
7. Abre una PR en nuestro repositorio y sigue la plantilla de PR para que podamos revisar los cambios de manera eficiente.


[[changelog]]
== 🗒 Registro de Cambios
Por favor refiérete a la
https://github.com/JonasPammer/ansible-role-core_dependencies/releases[Página de Lanzamientos de este Repositorio]
para un registro de cambios humano correspondiente
https://github.com/JonasPammer/ansible-role-core_dependencies/tags[Etiquetas (Versiones) de este Proyecto].

Ten en cuenta que este Proyecto se adhiere a la Versionación Semántica.
Por favor informa sobre cualquier cambio drástico accidental de una actualización de versión menor.


[[license]]
== ⚖️ Licencia

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

Copyright (c) 2022, Jonas Pammer

Se concede por la presente, de forma gratuita, a cualquier persona que obtenga una copia
de este software y los archivos de documentación asociados (el "Software"), el derecho a tratar
el Software sin restricciones, incluyendo sin limitación los derechos
a usar, copiar, modificar, fusionar, publicar, distribuir, sublicenciar y/o vender
copias del Software, y a permitir que las personas a quienes se les proporcione el Software lo hagan, sujeto a las siguientes condiciones:

El aviso de copyright anterior y este aviso de permiso deberán incluirse en todas
las copias o partes sustanciales del Software.

EL SOFTWARE SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O
IMPLICADA, INCLUYENDO, PERO NO LIMITÁNDOSE A, LAS GARANTÍAS DE COMERCIABILIDAD,
APTITUD PARA UN PROPÓSITO PARTICULAR Y NO INFRACCIÓN. EN NINGÚN CASO LOS
AUTORES O TITULARES DE DERECHOS DE AUTOR SERÁN RESPONSABLES DE NINGÚN RECLAMO, DAÑO O OTRA
RESPONSABILIDAD, YA SEA EN UNA ACCIÓN DE CONTRATO, TORTE U OTRA, QUE SURJA DE,
FUERA O EN CONEXIÓN CON EL SOFTWARE O EL USO O OTRAS MANEJOS EN EL
SOFTWARE.

----