Как хранить релизы/двоичные файлы в GitLab?

Я создаю рабочий процесс с Gitlab, Jenkins и - возможно - Nexus (мне нужно хранилище артефактов). Я хотел бы иметь GitLab для хранения выпусков/двоичных файлов - возможно ли это удобным способом?

Мне бы не хотелось иметь другую услугу, из которой можно было бы загрузить версию (и документацию), но чтобы она каким-то образом интегрировалась с менеджером репозитория, так же, как и выпуски, обрабатываются, например. GitHub. Любые подсказки?

Ответ 1

Обновление ноябрь 2015: GitLab 8.2 теперь поддерживает релизы.

С его API вы можете создавать и обновлять ссылки, связанные с тегом.
На данный момент это только возможность добавлять заметки о выпуске (текст уценки и вложения) в теги git (также известные как Releases).

сначала загрузите бинарный релиз
создайте новый выпуск и поместите ссылку на загруженный бинарный файл в описании

Обновление май 2019: GitLab 1.11 представляет интересный " Гостевой доступ к релизам ":

Теперь гостевые пользователи ваших проектов могут просматривать выпуски, которые вы опубликовали на странице выпусков.
Они смогут загружать ваши опубликованные артефакты, но им не разрешается загружать исходный код или просматривать информацию о репозитории, такую как теги и фиксации.

Оригинальный ответ март 2015

Это продолжается, и предлагается в предложениях 4156755:

Принимаем запросы на слияние для минимального предложения Ciro:

Для каждого тега репозитория на странице https://github.com/cirosantilli/test/releases/tag/3.0 разрешите загружать и скачивать список файлов.

Выгрузка и выгрузка могут быть сделаны прямо из списка тегов.

Если тег удаляется, загрузка уничтожается. (не принимал редактирование сообщения тега, упомянутое в последних комментариях)

Комментарии к этому предложению включают в себя:

Что делает его более интересным, так это следующий шаг.
Мне бы очень хотелось, чтобы можно было публично загружать артефакты из "релизов", не имея доступа к исходному коду (то есть делать источники приватными только для команды проекта, за исключением всего остального, такого как вики, "релизы", трекер проблем).

Однако такая дополнительная функция выглядит более общей, и я отправил отдельный запрос на эту функцию.

Тем не менее, я повторяю свою точку зрения здесь:
Хотя упрощенную версию "релизов" все еще приятно иметь, многие люди могут легко настроить внешний файловый сервер и указать URL-адреса в описании выпуска/тега на этот сервер за пределами GitLab.
Другими словами, "релизы" могут не выглядеть привлекательными сейчас без какой-либо будущей картины интеграции.

Ответ 2

Этот ответ будет в основном таким же, как и ответ от VonC, только что описанный пошагово для менее опытных пользователей CI.

Итак, допустим, у вас действительно классный коммит 30728cab, и вы хотели бы сделать эту версию своего кода новым выпуском...

1) Создать тег для вашего коммита

git tag -a MY_TAG_NAME 30728cab

После этой команды вам будет предложено заполнить описание, как при внесении новых изменений в код.

2) Вставьте тег в ваш удаленный репозиторий

Тэг НЕ будет помещен туда автоматически с вашими коммитами! Вы должны подтолкнуть их вручную к пульту.

git push REMOTE_REPO_NAME REMOTE_BRANCH_NAME MY_TAG_NAME

3) Загрузить файл

Теперь вы можете либо: а) загрузить файл в репозиторий GitLab, б) загрузить его в любое другое место и сохранить ссылку в обоих случаях.

ВНИМАНИЕ: Файлы, загруженные в репозиторий GitLab, нельзя легко удалить, и вы не сможете увидеть их ссылку позже!

Хотя я НЕ рекомендую загружать двоичные файлы в репозиторий по вышеуказанной причине, вы попросили об этом, поэтому вот способ:

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"

Закрытый токен можно создать в настройках пользователя → токены доступа.

Также, если вам действительно нужно удалить файл, вы можете экспортировать проект, вручную удалить updates папок из загруженного архива, удалить прежний удаленный репозиторий и создать новый, импортировав загруженный и измененный архив.

4) Создать релиз

Теперь мы можем наконец связать все это вместе с помощью 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"

Вы можете видеть, что Release по своей сути связан с определенным тегом, который впоследствии привязывается к конкретному коммиту. Затем соединение с двоичными файлами выполняется просто путем предоставления ссылок на эти файлы.

Забавно, что ваше description поддерживает Markdown, но действительно сложно написать какой-то более крупный документ *.md в такой громоздкой однострочной. Итак, я написал короткий скрипт Bash, который позволяет нам отложить файл Markdown в сторону, а затем он читает и отправляет его автоматически:

#!/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

так что вы можете использовать его так же, как

./upload_release.sh MY_RELEASE_NAME MY_TAG_NAME MY_PROJECT_ID MY_MARKDOWN_FILE_PATH MY_PRIVATE_TOKEN

А теперь это оно! У вас есть первый полный релиз!

Пока вы не поймете, что вы сделали ужасную опечатку в заголовке описания вашего релиза...

5) Удалить релиз (при необходимости)

Здесь тебе повезло! В отличие от загруженных двоичных файлов, вы также можете удалять свои релизы, используя REST API!

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

И так как набирать это несколько раз подряд довольно неудобно, я сделал еще один скрипт на 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

который можно использовать как ./delete_release.sh MY_PROJECT_ID MY_TAG_NAME MY_PRIVATE_TOKEN.

Ответ 3

Gitlab (сервер) сам для репозиториев git. Вы не должны хранить двоичные файлы в git. Nexus будет здесь. Вы можете добавить ссылку на nexus в ваше описание репозитория или файл readme (например, вы можете указать туда и на свою сборку jenkins).

Возможно, вы захотите взглянуть на GitLab Continuous Integration, которая интегрируется с Gitlab. Это похоже на Дженкинса. Я не знаю, идет ли это с хранилищем данных, например Nexus.

Ответ 4

Мы используем scp для копирования файлов, таких как двоичные файлы или отчеты, созданные в 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}