Python. Project Structure (III)

#python #ci #cd #docker

Índice:

Sección A. Estructurar un proyecto: apartado I, apartado II, apartado III, apartado IV, apartado V, apartado VI, apartado VII, apartado VIII.

En esta tercera parte configuraremos el entorno de Gitlab y el pipeline para que se lancen los tests cuando se realice una subida de datos al repositorio.

Preparar pipeline de Gitlab

Creamos el archivo .gitlab-ci.yml con el siguiente contenido:

# .gitlab-ci.yml
stages:
  - test

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

test:
  stage: test
  image: python:3.12
  before_script:
    - pip install -U pip
    - pip install -r requirements.txt -r requirements-dev.txt
    # descarga de los archivos protegidos (instalación y uso de download-secure-files)
    - curl --silent "https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer" | bash
    - download-secure-files
    - cp .secure_files/.env .
  script:
    - pytest
  rules:
    - when: always

Como ves, la única parte interesante en este pipeline es la utilización de los archivos protegidos.

Creamos el archivo .gitignore:

.venv/
_temp_/
*.py[cod]
.coverage
.pytest*
.env
.states

Hacemos el commit:

git add .
git commit -m 'Inicializar entorno del proyecto'

Preparar los archivos protegidos

Vamos a necesitar subir el archivo .env como archivo protegido, para ello, ve a tu proyecto en Gitlab y súbelo:

Settings > CI/CD Settings > Secure files
Selecciona tu archivo .env.

Realizar la subida al repositorio (push)

Como ya has realizado el commit solo te queda realizar un push:

git push -u origin release/000-initialize

El comando git indicado hace dos cosas esenciales en una sola operación:

Crea la rama remota: Sube tus commits y crea la nueva rama en el repositorio remoto.
Establece el seguimiento: Vincula tu rama local con la rama remota.

La opción '-u' es la abreviación de --set-upstream.

Establecer la rama `main`

Vaya error más tonto... hemos empezado a trabajar con una rama de trabajo sin tener la rama main (o master). Vamos a solucionarlo.

Lo primero será crearnos nuestra rama main en local y subirla a Gitlab:

git checkout -b main
git push -u origin main

En este momento tenemos lo mismo en ambas ramas.

Vayamos a Gitlab y configuremos correctamente el repositorio:

Settings > Repository > Protected branches > Add protected branch
- En 'Branch' seleccionamos 'main'.
- En 'Allowed to merge' seleccionamos 'Maintainers'
- En 'Allowed to push and merge' seleccionamos 'Maintainers'
- Mantenemos sin seleccionar 'Allowed to force push'.
- Y pulsamos en 'Protect'.
Ahora pulsamos el botón Unprotect de la rama 'release/000-initialize'.
En el menú Settings > Repository > Branch defaults:
- Desplegamos Default branch y seleccionamos main y pulsamos sobre Save changes.

A partir de este momento main solo será accesible a través de Merge Request... o sea, bajo petición de fusionado.

Apuntes

Normalmente la rama principal 'main' es la que debes crear en un primer momento. Una vez creada, debes realizar la rama pertinente para cada acción de trabajo.

Recuerda que la información confidencial nunca debes subirla a un repo, para ello hay diversas estrategias según sea el caso.

Estrategias:

Añade al .gitignore y .dockerignore los archivos con claves y configuraciones que no deben compartirse.
Crea archivos de ejemplo para explicar su contenido.
Cifra con git-secret aquellos archivos sensibles que deban subirse al repositorio.
Uso de variables secretas en la plataforma Gitlab/GitHub.
Scan de secretos:
- Pre-commits hooks con herramientas de escaneo (gitleaks, trufflehog) local.
- GitHub tiene una función de escaneo de repositorios para buscar e informarte de posibles secretos incluidos en tu código por descuido.