| ... | ... | @@ -62,15 +62,16 @@ Para hacerlo, y llevar el registro correcto, lo ideal es editar la versión dire |
|
|
|
|
|
|
|
**Pero cuidado**, si ese role ya se encontraba descargado, no se efectuarán cambios y en su lugar recibiremos una advertencia de que **será necesario también agregar el *flag* `--force`, con los peligros que esto implica si se estaba trabajando en el desarrollo de algún role. Usando `--force`, se eliminan por completo todos los roles antes de compezar la descarga nuevamente**
|
|
|
|
|
|
|
|
Del mismo modo, si algún compañero agregó nuevos roles al `requirements.yml` y deseas descargarlos con `ansible-galaxy`, puede que recibas algún error/advertencia que interrumpa la ejecución del utilitario; sea porque variaste la versión o estuviste trabajando en el desarrollo de alguno de los roles existentes. La solución práctica a este escenario, para no resignar funcionalidad (ya sabemos el por qué de los errores) es agregar a `ansible-galaxy install -r requirements.yml` el *flag* `--ignore-errors`. Este *flag*, a diferencia de `--force` no representa peligro alguno ya que no escribe absolutamente nada en los roles preexistentes.
|
|
|
|
Del mismo modo, si algún compañero agregó nuevos roles al `requirements.yml` y deseas descargarlos con `ansible-galaxy`, puede que recibas algún error/advertencia que interrumpa la ejecución del utilitario; sea porque variaste la versión o estuviste trabajando en el desarrollo de alguno de los roles existentes. La solución práctica a este escenario, para no resignar funcionalidad (ya sabemos y entendemos el por qué de los errores) es agregar a `ansible-galaxy install -r requirements.yml` el *flag* `--ignore-errors`. Este *flag*, a diferencia de `--force` no representa peligro alguno ya que no escribe absolutamente nada en los roles preexistentes.
|
|
|
|
|
|
|
|
|
|
|
|
## Nuestra forma de importar roles
|
|
|
|
|
|
|
|
Para la realidad del equipo *DevOps*, la forma mas práctica, robusta y consistente de utilizar el `requirements.yml` es **indicar siempre el `src` de *ansible.galaxy.com* y la versión del role que se está recuperando**, en lo posible mediante *tag* (sea un role propio o de terceros).
|
|
|
|
Para la realidad del equipo *DevOps*, la forma mas práctica, robusta y consistente de utilizar el `requirements.yml` es **indicar siempre**:
|
|
|
|
* `src` **desde *ansible.galaxy.com* para roles de terceros** (no tenemos acceso de escritura a sus repositorios)
|
|
|
|
* `src` **desde *github.com* para roles nuestros o *forks* de roles de terceros** (tenemos acceso de escritura a los repositorios) y **`name` idéntico al que corresponde en la galaxia** (`udelarinterior.<role_name>`) estén o no publicados)
|
|
|
|
* **la versión del role que se está recuperando**, en lo posible mediante *tag* (sea un role propio o de terceros).
|
|
|
|
|
|
|
|
**La única excepción a esta regla será el/los role/s sobre el que se esté trabajando en el momento dado, para el que localmente se editará el `src` de la galaxia por el correspondiente al repositorio Git. (Cabe aclarar que también deberemos trabajar de esta forma cuando el rol seleccionado aún no ha sido publicado en la galaxia, o en el caso de que le hemos enviamos una PR al manteiner del rol y esta aún no ha sido resuelta).**
|
|
|
|
**De este modo se garantiza que todos los miembos del equipo estén siempre en una versión consistente de cada role que no se actualizará por error. Podrá ser actualizada solo a conciencia al ejecutar el utilitario `ansible-galaxy` con la opción `--force` o nuestro playbook `actualizar_roles_github.yml` (parte de `entorno_dev_ops.yml`).**
|
|
|
|
|
|
|
|
De este modo se garantiza que todos los miembos del equipo estén siempre en una versión consistente de cada role que no se actualizará por error. **Podrá ser actualizada solo usando `--force` a conciencia al ejecutar el utilitario `ansible-galaxy`**
|
|
|
|
|
|
|
|
> En las herramientas DevOps, el *playbook* [`actualizar_roles_github.yml`](https://git.interior.edu.uy/adminsys/config/blob/master/dev_ops/actualizar_roles_github.yml) solo realiza modificaciones sobre roles descargados con `src` desde repositorios Git, por lo tanto no tendrá efecto sobre todos los roles sino solo sobre los que se están desarrollando en el momento (por ello tendrán `src` desde repos Git). |
|
|
|
> En las herramientas DevOps, el *playbook* [`actualizar_roles_github.yml`](https://git.interior.edu.uy/adminsys/config/blob/master/dev_ops/actualizar_roles_github.yml), tal como lo indica su nombre, solo realiza modificaciones sobre roles descargados con `src` desde repositorios Git. |
