create - ¿Cómo almacenar lanzamientos/binarios en GitLab?

git push tag (5)

Estoy creando un flujo de trabajo con Gitlab , Jenkins y, probablemente, Nexus (necesito un almacenamiento de artefactos). Me gustaría tener GitLab para almacenar lanzamientos / binarios : ¿es posible de una manera conveniente?

No me gustaría tener otro servicio desde el que se pueda descargar una versión (y documentación), sino integrarlo de alguna manera con el administrador de repositorios, al igual que las versiones se manejan en, por ejemplo, GitHub. ¿Alguna pista?

Actualización de noviembre de 2015: GitLab 8.2 ahora admite lanzamientos .

Con su API, ahora puede crear y actualizar una transmisión asociada a una etiqueta .
Por ahora, es solo la capacidad de agregar notas de lanzamiento (texto de descuento y archivos adjuntos) a las etiquetas git (también conocidas como lanzamientos).

primero upload el binario de lanzamiento
cree una nueva versión y coloque un enlace al binario cargado en la descripción

Actualización de mayo de 2019: GitLab 1.11 presenta un interesante " Acceso de invitado a lanzamientos ":

Ahora es posible que los usuarios invitados de sus proyectos vean los lanzamientos que ha publicado en la página Lanzamientos.
Podrán descargar sus artefactos publicados, pero no pueden descargar el código fuente ni ver información del repositorio como etiquetas y confirmaciones .

Respuesta original de marzo de 2015

Esto está en progreso y se sugiere en las sugerencias 4156755 :

Estamos aceptando solicitudes de fusión para la propuesta mínima de Ciro:

Para cada etiqueta de repositorio en https://github.com/cirosantilli/test/releases/tag/3.0 , permita cargar y descargar una lista de archivos.

La carga y descarga se pueden hacer directamente desde la vista de lista de etiquetas.

Si se elimina una etiqueta, las cargas se destruyen. (no estamos aceptando la edición del mensaje de etiqueta mencionada en comentarios recientes)

Los comentarios a esa sugerencia incluyen:

Lo que lo hace más interesante es el siguiente paso.
Realmente me gustaría una manera de permitir que el público descargue artefactos de "lanzamientos" sin poder acceder al código fuente (es decir, hacer que las fuentes sean privadas para el equipo del proyecto solo excepto cualquier otra cosa como wiki, "lanzamientos", rastreador de problemas).

Sin embargo, dicha característica adicional parece más genérica y presenté una solicitud de característica separada para eso .

Sin embargo, repito mi punto aquí:
Si bien la versión simplista de "lanzamientos" sigue siendo agradable, muchas personas pueden configurar fácilmente un servidor de archivos externo y señalar las URL en la descripción de lanzamiento / etiqueta a este servidor fuera de GitLab.
En otras palabras, los "lanzamientos" pueden no parecer atractivos ahora sin alguna imagen futura de integración.

Esta respuesta será básicamente la misma, como la de VonC, que se acaba de describir paso a paso para los usuarios de CI menos experimentados.

Entonces, digamos, que tiene un commit 30728cab realmente genial y le gustaría hacer de esta versión de su código una nueva versión ...

1) Crea una etiqueta para tu commit

git tag -a MY_TAG_NAME 30728cab

Después de este comando, se le pedirá que complete una descripción, al igual que cuando está confirmando nuevos cambios en su código.

2) Empuje la etiqueta a su repositorio remoto

¡La etiqueta NO se enviará allí automáticamente con sus confirmaciones! Debe empujarlos manualmente a su control remoto.

git push REMOTE_REPO_NAME REMOTE_BRANCH_NAME MY_TAG_NAME

3) Subir un archivo

Ahora puede a) cargar un archivo en el repositorio de GitLab, b) cargarlo en cualquier otro lugar y guardar el enlace en ambos casos.

ADVERTENCIA: ¡Los archivos cargados en el repositorio de GitLab no se pueden eliminar fácilmente y no puedes ver su enlace más tarde!

Si bien NO recomiendo cargar binarios en el repositorio debido a la razón anterior, lo solicitó, así que aquí está la manera:

curl --request POST --header "Private-Token: YOUR_PRIVATE_TOKEN" --form "file=@/PATH/TO/THE/FILE/file.txt" "https://MY_GITLAB_HOSTING.COM/api/v4/projects/MY_PROJECT_ID/uploads"

El token privado se puede crear en Configuración de usuario -> Tokens de acceso .

Además, si realmente necesita eliminar el archivo , puede exportar el proyecto , eliminar manualmente las updates de la carpeta del archivo descargado, eliminar el antiguo repositorio remoto y crear uno nuevo importando el archivo descargado y modificado.

4) Crear un lanzamiento

Ahora podemos finalmente unirlo todo usando Release .

curl --request POST --header ''Content-Type: application/json'' --header "Private-Token: YOUR_PRIVATE_TOKEN" --data ''{"name": "MY_RELEASE_NAME", "tag_name": "MY_TAG_NAME", "description": "Release with the binary LINK_TO_YOUR_BINARY"}'' "https://MY_GITLAB_HOSTING.COM/api/v4/projects/MY_PROJECT_ID/releases"

Puede ver que Release está inherentemente vinculado con una etiqueta específica, que posteriormente está vinculada a una confirmación específica. La conexión con los archivos binarios se realiza simplemente proporcionando enlaces a esos archivos.

Lo curioso es que su description compatible con Markdown , pero es realmente difícil escribir un documento *.md más grande en una línea engorrosa. Así que escribí un breve script de Bash, que nos permite escribir el archivo Markdown a un lado y luego lo lee y lo envía automáticamente:

#!/bin/bash RELEASE_NAME="$1" TAG_NAME="$2" PROJECT_ID="$3" DESCRIPTION_FILE_PATH="$4" PRIVATE_TOKEN="$5" if [ "$5" == "" ]; then echo "Missing parameter! Parameters are RELEASE_NAME, TAG_NAME, PROJECT_ID, DESCRIPTION_FILE_PATH and PRIVATE_TOKEN."; exit 1; fi DESCRIPTION='''' # Load data from file while read -r line; do DESCRIPTION="${DESCRIPTION}${line}/n"; done < "${DESCRIPTION_FILE_PATH}" curl --request POST/ --header ''Content-Type: application/json''/ --header "Private-Token: ${PRIVATE_TOKEN}"/ --data-binary "{/"name/": /"${RELEASE_NAME}/", /"tag_name/": /"${TAG_NAME}/", /"description/": /"${DESCRIPTION}/"}"/ "https://MY_GITLAB_HOSTING.com/api/v4/projects/${PROJECT_ID}/releases" echo

para que puedas usarlo como

./upload_release.sh MY_RELEASE_NAME MY_TAG_NAME MY_PROJECT_ID MY_MARKDOWN_FILE_PATH MY_PRIVATE_TOKEN

Y ahora eso es todo! ¡Tienes tu primer lanzamiento completo!

Hasta que te des cuenta, que has cometido un error tipográfico terrible en el encabezado de la descripción de tu lanzamiento ...

5) Eliminar una versión (si es necesario)

¡Aquí tienes suerte! ¡A diferencia de los archivos binarios cargados, también puede eliminar sus lanzamientos utilizando la API REST!

curl --request DELETE --header "Private-Token: MY_PRIVATE_TOKEN" "https://MY_GITLAB_HOSTING.com/api/v4/projects/MY_PROJECT_ID/releases/MY_TAG_NAME"

Y como todavía es bastante molesto escribir esto varias veces seguidas, hice otro script Bash:

#!/bin/bash PROJECT_ID=$1 TAG_NAME=$2 PRIVATE_TOKEN=$3 if [ "$3" == "" ]; then echo "Missing parameter! Parameters are PROJECT_ID, TAG_NAME and PRIVATE_TOKEN."; exit 1; fi curl --request DELETE --header "Private-Token: ${PRIVATE_TOKEN}" "https://MY_GITLAB_HOSTING.com/api/v4/projects/${PROJECT_ID}/releases/${TAG_NAME}" echo

que se puede usar como ./delete_release.sh MY_PROJECT_ID MY_TAG_NAME MY_PRIVATE_TOKEN .

Estamos usando scp para copiar archivos, como binarios o informes, generados en GitlabCI.

# capture test exit code set +e bash build/ci/test.sh; TESTS_EXIT_CODE=$? set -e # copy reports sshpass -p "$SFTP_PASS" ssh -o StrictHostKeyChecking=no [email protected] "mkdir -p ${CI_REPORTS_PATH}" sshpass -p "$SFTP_PASS" scp -r ${CI_APP_VOLUME}/tests/_output/* [email protected]:${CI_REPORTS_PATH} # return test exit-code exit ${TESTS_EXIT_CODE}

Estoy usando una herramienta de línea de comandos que he escrito en Python como acceso directo. Realiza algunos pasos de los métodos API descritos en respuestas anteriores (Cargar, Liberar, Eliminar Liberación).

Puede verificar el código fuente o simplemente usarlo usted mismo.

Para una versión aún más simple, si alguien está interesado en hacer esto con python y request.py; Es bastante trivial.

Para subir

import requests secret_token = "<your secret token>" project_id = "<your project id>" file_path = "your_file.txt" api_root = "https://gitlab.com/api/v4" headers = { ''PRIVATE-TOKEN'': secret_token, } uri = ''{}/projects/{}/uploads''.format(api_root, project_id) files = { ''file'': open(file_path, ''rb'') } r_upload = requests.post(uri, headers=headers, files=files) if(r_upload.status_code != 201 and r_upload.status_code != 200): raise ValueError(f"Upload API responded with unvalid status {r_upload.status_code}") # noqa: E501 upload = r_upload.json()

Cargar devuelve un upload con el enlace y el enlace con formato de descuento. Encontré que Markdown formateado es bastante útil para la descripción de la versión . Ya que tiene que agregar el enlace a la descripción usted mismo.

Para crear un lanzamiento

import requests secret_token = "<your secret token>" project_id = "<your project id>" api_root = "https://gitlab.com/api/v4" desc = """ Your release description. **You can use markdown !** Don''t forget to add download link here. """ headers = { ''PRIVATE-TOKEN'': secret_token, } data = { "description": desc } r_new_release = requests.post(uri, data=data, headers=headers) if(r_new_release.status_code != 201 and r_new_release.status_code != 200): raise ValueError(f"Releases API responded with invalid status {r_new_release.status_code}") new_release = r_new_release.json()

JSON Response es el lanzamiento .

Para los otros pasos, básicamente siga las pautas de API y realice los ajustes. Todos ellos son bastante similares.

Gitlab (servidor) en sí es para repositorios git. No se supone que almacene binarios en git. Nexus estaría aquí por el camino a seguir. Puede agregar un enlace a nexus en la descripción de sus repositorios o en el archivo léame (como puede señalar allí también a su compilación jenkins).

Es posible que desee echar un vistazo a la integración continua de GitLab que se integra con Gitlab. Eso parece ser más como Jenkins. No sé si viene con un almacenamiento de datos como Nexus.