Saltar al contenido

Artefacto de Gitlabs de un proyecto utilizado en otros proyectos

Solución:

En GitLab silver y premium, está disponible $ CI_JOB_TOKEN, que permite el siguiente fragmento .gitlab-ci.yaml:

build_submodule:
  image: debian
  stage: test
  script:
  - apt update && apt install -y unzip
  - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test&job_token=$CI_JOB_TOKEN"
  - unzip artifacts.zip
  only:
  - tags

Sin embargo, si no tiene suscripciones de gitlab plateadas o superiores, pero confía en niveles gratuitos, también es posible utilizar la API y los activadores de canalización.

Asumamos que tenemos proyecto A edificio app.jar que es necesario por proyecto B.

Primero, necesitará un token de API. Ir a Profile settings/Access Tokens página para crear uno, luego guárdelo como una variable en proyecto B. En mi ejemplo es GITLAB_API_TOKEN.

En la configuración de CI / CD de proyecto B agregue un nuevo disparador, por ejemplo, “Proyecto A construido”. Esto le dará un token que puede copiar. Abierto proyecto A.gitlab-ci.yaml y copie el trigger_build: sección de proyecto Bsección de activación de la configuración de CI / CD.

Proyecto A:

trigger_build:
  stage: deploy
  script:
    - "curl -X POST -F token=TOKEN -F ref=REF_NAME https://gitlab.example.com/api/v4/projects/${PROJECT_B_ID}/trigger/pipeline"

Reemplace TOKEN con ese token (mejor, guárdelo como una variable en proyecto A – entonces tendrás que hacerlo token=${TRIGGER_TOKEN_PROJECT_B} o algo), y reemplace REF_NAME con su rama (p. ej. master).

Entonces, en proyecto B, podemos escribir una sección que solo se base en disparadores y recupere los artefactos.

Proyecto B:

download:
  stage: deploy
  only:
    - triggers
  script:
    - "curl -O --header 'PRIVATE-TOKEN: ${GITLAB_API_TOKEN}' https://gitlab.example.com/api/v4/projects/${PROJECT_A_ID}/jobs/${REMOTE_JOB_ID}/artifacts/${REMOTE_FILENAME}"

Si conoce la ruta del artefacto, puede reemplazar ${REMOTE_FILENAME} con eso, por ejemplo build/app.jar. El ID del proyecto se puede encontrar en la configuración de CI / CD.

Extendí el guión en proyecto A para pasar la información restante como se documenta en la sección de configuración del disparador:

Agregar variables[VARIABLE]=VALUE a una solicitud de API. Los valores variables se pueden utilizar para distinguir entre tuberías activadas y tuberías normales.

Entonces, el disparador pasa REMOTE_JOB_ID y REMOTE_FILENAME, pero, por supuesto, puede modificar esto cuando lo necesite:

curl -X POST 
     -F token=TOKEN 
     -F ref=REF_NAME 
     -F "variables[REMOTE_FILENAME]=build/app.jar" 
     -F "variables[REMOTE_JOB_ID]=${CI_JOB_ID}" 
     https://gitlab.example.com/api/v4/projects/${PROJECT_B_ID}/trigger/pipeline

Hola, debes echar un vistazo a un script llamado get-last-successful-build-artifact.sh y desarrollado por morph027.

https://gitlab.com/morph027/gitlab-ci-helpers

Este script permite descargar un artefacto y descomprimirlo en la raíz del proyecto. Utiliza la API de Gitlab para recuperar la última compilación exitosa y descargar el artefacto correspondiente. Puedes combinar varios artefactos y descomprimirlos donde quieras con solo actualizar un poco el script.

Actualmente también estoy iniciando una biblioteca PHP para manejar artefactos de compilación, pero está en una etapa muy temprana y está vinculada con laravel por el momento.

Por el momento, no hay una manera fácil de manejar el uso de artefactos entre proyectos, debe crear el suyo propio utilizando esas herramientas.

Creo que usar el ejecutor de shell no es la solución correcta, es muy peligroso porque no puede verificar el archivo en el servidor utilizado durante la compilación.

Espero que esto ayude 🙂

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *