jonaspammer.bootstrap

// Este archivo está siendo generado por .github/workflows/gh-pages.yml - ¡todos los cambios locales se perderán eventualmente!
= ansible-role-bootstrap
Jonas Pammer <[email protected]>;
: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[Versión en Galaxy]]
// Insignias de estado muy relevantes
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[Pruebas CI]]

Un rol de Ansible para preparar un sistema Linux para ser gestionado por Ansible.

Este rol utiliza el https://docs.ansible.com/ansible-core/2.16/collections/ansible/builtin/raw_module.html[`módulo ansible.builtin.raw`] 
en combinación con un "sistema de determinación de sistema operativo" propio 
para instalar el conjunto mínimo de paquetes requeridos (`python` y `sudo`) 
para permitir que Ansible gestione un sistema.

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

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

[NOTA]
.RENUNCIA
=====
Este rol es un derivado de https://github.com/robertdebock/ansible-role-bootstrap/releases/tag/5.2.12[robertdebock/ansible-role-bootstrap v5.2.12 (27 de enero de 2022)] 
(Licencia Apache 2.0, Copyright Robert de Bock ([email protected])) 
con varios cambios/arreglos. +
Extracto de cambios de https://github.com/JonasPammer/ansible-role-bootstrap/releases[/releases] a continuación (con problemas acompañantes en el repositorio de robertdebock):

* El rol en sí debería pre-cargar el caché del gestor de paquetes:
  https://github.com/robertdebock/ansible-role-bootstrap/pull/57[robertdebock/ansible-role-bootstrap#57]
  ( arreglo en 
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/43[JonasPammer#43];
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/50[JonasPammer#50]
  )
* cambió el valor predeterminado de `become` a `false`, agregó la capacidad de definir `become_user` por separado de `ansible_user`:
  https://github.com/robertdebock/ansible-role-bootstrap/issues/63[robertdebock/ansible-role-bootstrap#63]
  ( arreglo en 
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/61[JonasPammer#61]
  )
* cambió el valor predeterminado de `bootstrap_become_user` a root
* usar `bootstrap_become_user` en los pasos de módulos de ansible también
* hacer que el rol sea compatible con podman especificando `/bin/sh`
  https://github.com/robertdebock/ansible-role-bootstrap/pull/66[robertdebock/ansible-role-bootstrap#66]
  ( arreglo en 
  https://github.com/JonasPammer/ansible-role-bootstrap/pull/62[JonasPammer#62]
  )
=====

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: bootstrap
  description: Un rol de Ansible para preparar un sistema Linux para ser gestionado por Ansible. Basado en el rol de robertdebock.

  author: jonaspammer
  license: "MIT"

  min_ansible_version: "2.9"
  platforms:
    - 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:
    - bootstrap
    - python
    - sudo

dependencies: []
----

[[requirements]]
== 📌 Requisitos
// Cualquier requisito previo que puede no estar cubierto por este rol o Ansible debería mencionarse aquí.
El usuario de Ansible necesita poder `become`.

[[variables]]
== 📜 Variables del Rol
// Una descripción de las variables configurables para este rol debe ir aquí
// y cualquier variable que pueda/deba ser configurada a través de parámetros para el rol.
// Cualquier variable que se lea de otros roles y/o del ámbito global (es decir, hostvars, variables de grupo, etc.)
// también deben mencionarse aquí.

[source,yaml]
----
bootstrap_user: root
----
https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#term-ansible_user[Nombre de usuario]
utilizado para conectarse a la máquina para las tareas `raw` primarias de _recolección de hechos simples_ / _instalación_.

[source,yaml]
----
bootstrap_become: false
bootstrap_become_user: root
----
Variables `become` y `become_user` pasadas a la mayoría de las tareas reales.

El valor por defecto de `bootstrap_become` se estableció en `false` 
porque se asumió que `sudo` no está disponible 
antes de la inicialización.

[source,yaml]
----
bootstrap_wait_for_host: false
----
Si se espera que el host esté disponible en `ansible_port` (22).

[source,yaml]
----
bootstrap_timeout: 3
----
Número máximo de segundos para esperar a que el sistema remoto sea accesible/utilizable antes de fallar.

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

Cada variable enumerada en esta sección 
se define dinámicamente al ejecutar este rol (y solo se puede sobrescribir usando `ansible.builtin.set_facts`) _y_ 
se supone que se utilizará 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 usando 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"]
|===
|Etiquetas | Propósito

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

|===

Puedes usar Ansible para omitir tareas o ejecutar solo ciertas tareas utilizando estas etiquetas. De forma predeterminada, se ejecutan todas las tareas cuando no se especifican etiquetas.

[[dependencies]]
== 👫 Dependencias
// Una lista de otros roles debería ir aquí,
// además de cualquier detalle en relación con los parámetros que pueden necesitar ser configurados para otros roles,
// o variables que se utilizan de otros roles.

[[example_playbooks]]
== 📚 Ejemplos de uso de Playbook
// Incluir ejemplos de cómo usar este rol en un playbook para escenarios comunes también es agradable para los usuarios:

[IMPORTANTE]
====
Debes desactivar la propiedad `gather_facts` del play en el que se usa este rol.
Si este rol finaliza correctamente, llamará por sí mismo al https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html[
módulo de configuración de Ansible] (efecto equivalente a que `gather_facts: true` lo daría).

No debe haber tareas antes de este rol.
====

.Playbook Mínimo
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Inicializar máquinas Linux para ser gestionadas por Ansible.
  become: false
  gather_facts: false

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

.Cambiando el usuario de inicialización (por ejemplo, cuando root no es una opción)
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Inicializar máquinas Linux para ser gestionadas por Ansible.
  become: false
  gather_facts: false

  vars:
    bootstrap_user: "{{ ansible_user }}"

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


.Utilizando become true (por ejemplo, cuando sabes que al menos tienes un sudo utilizable)
====
[source,yaml]
-----
---
- hosts: servers:&provisioned
  name: Inicializar máquinas Linux para ser gestionadas por Ansible.
  become: true
  gather_facts: false

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

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

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

Un rol puede funcionar en diferentes *distribuciones*, como Red Hat Enterprise Linux (RHEL),
incluso si no hay prueba para esta distribución exacta.

// buena referencia para seguir - el proyecto más estrellado y fijado 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 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[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 meses)
| 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]]
== 🧪 Versiones de Ansible probadas

Las versiones de Ansible probadas intentan mantenerse equivalentes al 
https://github.com/ansible-collections/community.general#tested-with-ansible[
patrón de soporte de la colección `community.general` de Ansible].
Hasta 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[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Commits Convencionales]]
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[estado de pre-commit]]
// image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, link=https://github.com/pre-commit/pre-commit]

[[development-system-dependencies]]
=== 📌 Dependencias de la Máquina de Desarrollo

* Python 3.10 o mayor
* Docker

[[development-dependencies]]
=== 📌 Dependencias del Desarrollo
Las dependencias de desarrollo se definen en un 
https://pip.pypa.io/en/stable/user_guide/#requirements-files[archivo de requisitos de pip] 
llamado `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 de shell actual
$ python3 -m venv venv
$ source venv/bin/activate

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

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

Por favor echa un vistazo a mis https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[
Directrices de Desarrollo de Roles de Ansible].

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

[[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-bootstrap/actions/workflows/release-to-galaxy.yml[
un flujo de trabajo de CI de GitHub]
(image:https://github.com/JonasPammer/ansible-role-bootstrap/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
Las pruebas automáticas se ejecutan en cada contribución utilizando Flujos de Trabajo de GitHub.

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

La prueba de las moléculas también incluye un paso que lincea todos los playbooks de Ansible usando 
https://github.com/ansible/ansible-lint#readme[`ansible-lint`] 
para verificar las mejores prácticas y el comportamiento que podría mejorarse potencialmente.

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á por la molécula:

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

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

==== 🐛 Depuración de un Contenedor de Moléculas

1. Ejecuta tus pruebas de moléculas 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 : (redactado).] pas: [************************]
  falló: [instancia-py3-ansible-9] => changed=false
...
 pas: [___________________________________ resumen ____________________________________]
  pre-commit: los comandos tuvieron éxito
ERROR:   py3-ansible-9: comandos fallidos
----

2. Encuentra el nombre del contenedor docker provisionado por la molécula:
+
[subs="quotes"]
----
$ *docker ps*
#30e9b8d59cdf#   geerlingguy/docker-debian12-ansible:latest   "/lib/systemd/systemd"   hace 8 minutos   Arriba hace 8 minutos                                                                                                    instancia-py3-ansible-9
----

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

root@instance-py3-ansible-2:/#
----
+
[PUNTO]
====
Si el fallo que intentas depurar es parte de tu paso `verify.yml` y no de `converge.yml`,
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 en:

* `/var/tmp/vars.yml` (contiene variables de host bajo la clave `hostvars`)
* `/var/tmp/environment.yml`

¡Usa `grep`, `cat` o transfieres los archivos como desees!
====
+
[PUNTO]
=====
También puede ser útil 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 determinada. +
Esto permite revisar la diferencia entre las ejecuciones 
y así ayudar en la depuración de lo que causó la falla o degradado en general.

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

4. Después de terminar 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]]
=== 🧃 PUNTO: 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 docker dentro de él (Docker-In-Docker, dind),
lo que permite la ejecución de moléculas.

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],
opcionalmente siguiendo la sección __Instalación__ de la página vinculada. +
Esto incluye: instalar Docker, instalar Visual Studio Code y 
instalar 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 adjunto para entrar en ella. 
*De lo contrario,* también puedes ejecutar el comando de Visual Studio `Remote-Containers: Open Folder in Container` tú mismo (_Vista - Paleta de Comandos_ -> _escribe el comando mencionado_).

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

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

El procedimiento está descrito en https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[
en la documentación oficial del 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 fue modelado originalmente] 
usando https://github.com/cruft/cruft[cruft] (si es posible) o alteración manual (de ser necesario) 
en la mejor medida posible.

.Ejemplo oficial de uso de `cruft update`
____
image::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 lanzamiento adecuado de GitHub será creado 
por el mantenedor del repositorio para proporcionar un registro de cambios humano con un título y descripción.

[[pre-commit]]
=== ℹ️ Convenciones Generales de Linting y Formato
Las convenciones generales de linting y formato son 
https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*sostenidas automáticamente* a estándares] 
por varios https://pre-commit.com/[módulos `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 a través de ganchos que alteran archivos automáticamente.

[NOTA]
====
Para no confundir:
Aunque algunos ganchos de pre-commit pueden ser capaces de advertirte sobre fallos de análisis de scripts en 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 obtener información sobre pruebas, consulta <<testing>>.
====

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

Esto se puede hacer ingresando en el directorio de tu proyecto clonado y ejecutando `pre-commit install`.
Hacer esto hará que git ejecute comprobaciones de pre-commit en cada confirmación que realices,
abandonando la confirmación si algún gancho falla.

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

== 💪 Contribuciones
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[Abre en Visual Studio Code]]
image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[Pull Requests Bienvenidos]

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

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

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

Seguir estas pautas ayuda a comunicar que respetas el tiempo de los desarrolladores que gestionan y desarrollan este proyecto de código abierto.
A cambio, deberían reciprocitar ese respeto al abordar tu problema, evaluar cambios y ayudarte a finalizar tus pull requests.

[[cookiecutter--contributing]]
=== 🍪 CookieCutter
Este proyecto debe muchos de sus archivos a 
https://github.com/JonasPammer/cookiecutter-ansible-role[el CookieCutter del que fue modelado originalmente].

Por favor verifica si la edición que tienes en mente es realmente aplicable a la plantilla 
y si es así, realiza un cambio adecuado allí. 
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 casual 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 los pull requests se combinan en una sola confirmación en el proyecto.
Solo los colaboradores principales, es decir, aquellos con derechos para realizar 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 funcione).

=== 🚀 Comenzando

Las contribuciones se realizan a este repositorio a través de Problemas y Pull Requests (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 recursos y consejos sobre cómo comenzar.

==== Problemas

Los problemas deben utilizarse para informar problemas, solicitar nuevas características, o para discutir cambios potenciales *antes* de crear un PR.
Cuando https://github.com/JonasPammer/ansible-role-bootstrap/issues/new[
creas un nuevo problema], se cargará una plantilla que te guiará a través de la recopilación y provisión de la información que necesitamos para investigar.

Si encuentras un problema que aborde 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 está afectando a más que solo al reportante.

==== Pull Requests

Los PRs a este proyecto siempre son bienvenidos y pueden ser una forma rápida de que tu arreglo o mejora se incluya en la siguiente versión.
https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[En general], los PRs deben:

* Solo arreglar/agregar la funcionalidad en cuestión *O* abordar problemas de estilo/espacios en blanco ampliamente difundidos, no ambos.
* Agregar pruebas unitarias o de integración para la funcionalidad fijada o cambiada (si ya existe una suite de pruebas).
* *Abordar una sola preocupación*
* *Incluir documentación* en el repositorio
* Ser acompañados por una completa plantilla de Pull Request (cargada automáticamente cuando se crea un PR).

Para cambios que aborden funcionalidades principales o que requieran cambios disruptivos (por ejemplo, un lanzamiento importante),
es mejor abrir un problema para discutir tu propuesta primero.

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

1. Haz un fork del repositorio en 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 modificaciones en la rama
5. Siguiendo cualquier pauta de formato y pruebas específica de este repositorio
6. Sube los cambios a tu fork
7. Abre un 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 consulta la 
https://github.com/JonasPammer/ansible-role-bootstrap/releases[Página de Lanzamientos de este Repositorio]
para un registro de cambios humano correspondiente a las 
https://github.com/JonasPammer/ansible-role-bootstrap/tags[Etiquetas (Versiones) de este Proyecto].

Ten en cuenta que este proyecto sigue el versionado semántico.
Por favor informa sobre cualquier cambio accidental que rompa la compatibilidad de una actualización de versión menor.

== ⚖️ Licencia

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

Copyright (c) 2022, Jonas Pammer

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

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

EL SOFTWARE SE PROPORCIONA "TAL CUAL", SIN GARANTÍA DE NINGÚN TIPO, EXPLÍCITA O IMPLÍCITA, INCLUYENDO PERO NO LIMITÁNDOSE A LAS GARANTÍAS DE COMERCIALIZACIÓN, 
ADECUACIÓN A UN PROPÓSITO PARTICULAR Y NO INFRACCIÓN. EN NINGÚN CASO LOS 
AUTORES O TITULARES DE LOS DERECHOS DE AUTOR SERÁN RESPONSABLES POR CUALQUIER RECLAMO, DAÑOS O CUALQUIER OTRA 
RESPONSABILIDAD, YA SEA EN UNA ACCIÓN DE CONTRATO, AGRAVIO O DE CUALQUIER OTRA MANERA, QUE SURJA DE, FUERA O EN CONEXIÓN CON EL SOFTWARE O EL USO O CUALQUIER OTRO TRATO EN EL SOFTWARE.
----