Solución:
Actualización de octubre de 2020:
GitLab 13.5 ahora ofrece:
Adjuntar activos binarios a las versiones
Si actualmente no está utilizando GitLab para sus lanzamientos porque no puede adjuntar binarios a los lanzamientos, su flujo de trabajo se ha vuelto mucho más simple.
Ahora tiene la capacidad de adjuntar binarios a una etiqueta de lanzamiento desde el
gitlab.ci-yml. Esto amplía el soporte de Release Assets para incluir binarios, en lugar de solo enlaces de activos o código fuente. Esto hace que sea aún más fácil para sus equipos de desarrollo adoptar GitLab y usarlo para automatizar su proceso de lanzamiento.
Consulte la documentación y el problema.
Actualización de noviembre de 2015: GitLab 8.2 ahora admite versiones.
Con su API, ahora puede crear y actualizar un relase asociado a una etiqueta.
Por ahora, es solo la capacidad de agregar notas de la versión (texto de rebajas y archivos adjuntos) a las etiquetas de git (también conocidas como Versiones).
- primero cargue 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 las versiones“:
Ahora es posible que los usuarios invitados de sus proyectos vean los lanzamientos que ha publicado en la página de 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:
Aceptamos 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. 2. La carga y descarga se puede realizar directamente desde la vista de lista de etiquetas. 3. Si se quita una etiqueta, las cargas se destruyen. (no aceptamos 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 solo para el equipo del proyecto, excepto cualquier otra cosa como wiki, “lanzamientos”, seguimiento de problemas).
Sin embargo, esta función adicional parece más genérica y envié una solicitud de función por separado para eso.
Sin embargo, repito mi punto aquí:
Si bien la versión simplista de “lanzamientos” todavía es agradable de tener, muchas personas pueden configurar fácilmente un servidor de archivos externo y señalar 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 una imagen futura de integración.
Esta respuesta será básicamente la misma que la de VonC, que se acaba de describir paso a paso para los usuarios de CI menos experimentados.
Entonces, digamos, que tiene una confirmación 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 compromiso
git tag -a MY_TAG_NAME 30728cab
Después de este comando, se le pedirá que complete una descripción, al igual que cuando realiza 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! Necesita enviarlos manualmente a su control remoto.
git push REMOTE_REPO_NAME REMOTE_BRANCH_NAME MY_TAG_NAME
3) Cargar 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 por el motivo anterior, lo solicitó, así que aquí está el camino:
curl --request POST --header "Private-Token: YOUR_PRIVATE_TOKEN" --form "[email protected]/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.
También, si realmente necesitabas borrar el archivo, puede exportar el proyecto, eliminar manualmente la carpeta updates de su archivo descargado, elimine el repositorio remoto anterior y cree uno nuevo importando su archivo descargado y modificado.
4) Crea un comunicado
Ahora finalmente podemos 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 binarios se realiza simplemente proporcionando enlaces a esos archivos.
El punto curioso es que tu description es compatible con Markdown, pero es muy difícil escribir más *.md documento en una sola línea tan engorrosa. Así que escribí un breve script 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 eso es todo! ¡Tienes tu primer lanzamiento completo!
Hasta que se dé cuenta de que ha cometido un error tipográfico terrible en el encabezado de la descripción de su lanzamiento …
5) Eliminar una versión (si es necesario)
¡Aquí tienes suerte! A diferencia de los binarios cargados, también puede eliminar sus versiones 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 sigue siendo bastante molesto escribir esto varias veces seguidas, hice otro script de 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.