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 🙂