Verificando autenticación…

Saltar al contenido principal

Uso directo del componente code/version

Esta página es para quien quiere incluir el componente code/version directamente en su pipeline, fuera de los pipelines estándar por lenguaje.

Si usas golang-service, java-service, react-service o python-service, ve a la guía de uso — el componente ya viene configurado.

Cuándo tiene sentido usarlo directamente​

  • Tu proyecto tiene un stack no cubierto por los pipelines estándar.
  • Tienes un monorepo con múltiples componentes versionados de forma independiente.
  • Necesitas control explícito sobre el stage, los runners o los inputs del job.

Cómo incluirlo​

include:
  - component: $CI_SERVER_FQDN/latamairlines/andes/pipelines/components/code/version@1.0.0
    inputs:
      job_name: "detect-version"
      stage: "prepare"

stages:
  - prepare
  - build

build-image:
  stage: build
  needs:
    - job: detect-version
      artifacts: true
  script:
    - echo "Publicando versión ${VERSION}"
    - docker build -t my-image:${VERSION_SEMVER_OCI} .

Fija siempre la versión del componente (@1.0.0) para evitar cambios inesperados.

Componente complementario: deploy/publish​

El componente code/version solo detecta y calcula — no crea tags Git ni publica releases. Para cerrar el ciclo necesitas el componente deploy/publish, que consume los artefactos de version.env y se encarga de:

  • Crear el tag Git en el repositorio.
  • Publicar la imagen al registry correspondiente.
  • Registrar el release en GitLab con las notas del CHANGELOG.md.
  • Eliminar los tags RC cuando se publica un stable.

Los pipelines estándar por lenguaje incluyen ambos componentes preconfigurados. Si usas code/version directo, necesitas también incluir deploy/publish o implementar esa lógica tú mismo.

Referencia completa​

Los inputs disponibles, la lógica de detección por stack, las variables producidas en version.env y los comportamientos especiales (idempotencia, auto bump de patch, rolling OCI tags) están documentados en el README del componente:

README — componente code/version

Contexto ANDES​

Al usar el componente directamente aplican las mismas reglas que con los pipelines estándar:

  • En la rama main con estrategia tbd (el default), el componente genera un RC automáticamente. Para publicar un stable, pasa release_candidate con el ticket Jira del cambio.
  • El validation_mode resuelve a strict en main y MRs a main. Asegúrate de que tu CHANGELOG.md tenga una entrada con contenido para el VERSION_CORE antes de mergear.
  • El proceso de pase a producción es el mismo que con los pipelines estándar. Ver Pase a producción.

Referencias​