git 如何在 GitLab 中存储版本/二进制文件？

How to store releases/binaries in GitLab?

提问by Kasia Gauza

I am building a workflow with Gitlab, Jenkinsand - probably - Nexus(I need an artifact storage). I would like to have GitLab to store releases/binaries- is it possible in a convenient way?

我正在使用Gitlab、Jenkins和 - 可能 - Nexus构建工作流程（我需要一个工件存储）。我想让 GitLab 存储发布/二进制文件- 是否有可能以方便的方式？

I would not like to have another service from which a release (and documentation) could be downloaded but to have it somehow integrated with repository manager, just like releases are handled in e.g. GitHub. Any clues?

我不希望有另一个可以从中下载发布（和文档）的服务，而是让它以某种方式与存储库管理器集成，就像在 GitHub 中处理发布一样。有什么线索吗？

采纳答案by VonC

Update Nov. 2015: GitLab 8.2 now supports releases.

2015 年 11 月更新：GitLab 8.2 现在支持发布。

With its API, you now can create and update a relase associated to a tag.
For now, it is only the ability to add release notes (markdown text and attachments) to git tags (aka Releases).

借助其 API，您现在可以创建和更新与标签关联的 relase。
目前，它只能将发行说明（降价文本和附件）添加到 git 标签（又名发行版）。

• first uploadthe release binary
• create a new releaseand place a link to the uploaded binary in the description

• 首先上传发布二进制文件
• 创建一个新版本并在描述中放置一个指向上传二进制文件的链接

Update May 2019: GitLab 1.11 introduces an interesting "Guest access to Releases":

2019 年 5 月更新：GitLab 1.11 引入了一个有趣的“ Guest access to Releases”：

It is now possible for guest users of your projects to view releases that you have published on the Releases page.
They will be able to download your published artifacts, but are not allowed to download the source code nor see repository information such as tags and commits.

现在，您项目的来宾用户可以查看您在“发布”页面上发布的发布。
他们将能够下载您发布的工件，但不能下载源代码，也不能查看存储库信息，例如标签和提交。

---

---

Original answer March 2015

原始答案 2015 年 3 月

This is in progress, and suggested in suggestions 4156755:

这正在进行中，并在建议 4156755中提出建议：

We're accepting merge requests for the minimal proposal by Ciro:

1. For each repository tag under https://github.com/cirosantilli/test/releases/tag/3.0, allow to upload and download a list of files.
2. The upload and download can be done directly from the tag list view.
3. If a tag gets removed, the uploads are destroyed. (we're not accepting the tag message edit mentioned in recent comments)

我们正在接受 Ciro 对最小提案的合并请求：

1. 对于https://github.com/cirosantilli/test/releases/tag/3.0下的每个存储库标签，允许上传和下载文件列表。
2. 上传和下载可以直接从标签列表视图中完成。
3. 如果标签被移除，上传的内容将被销毁。（我们不接受最近评论中提到的标签消息编辑）

---

---

The comments to that suggestion include:

对该建议的评论包括：

What makes it more interesting is the next step.
I would really like a way to let public download artifacts from "releases" without being able to access source code (i.e. make sources private for project team only except anything else like wiki, "releases", issue tracker).

However, such additional feature looks more generic and I submitted a separate feature request for that.

Nevertheless, I repeat my point here:
While the simplistic version of "releases" is still nice to have, many people can easily set up external file server and point URLs in release/tag description to this server outside GitLab.
In other words, "releases" may not look attractive now without some future picture of integration.

更有趣的是下一步。
我真的很想有一种方法可以让公共从“发布”下载工件而不能访问源代码（即，除了维基、“发布”、问题跟踪器等其他任何东西外，只为项目团队将源设为私有）。

但是，这样的附加功能看起来更通用，我为此提交了单独的功能请求。

尽管如此，我在这里重申我的观点：
虽然“发布”的简单版本仍然很好，但许多人可以轻松设置外部文件服务器并将发布/标签描述中的 URL 指向 GitLab 之外的该服务器。
换句话说，如果没有一些未来的整合图景，“发布”现在可能看起来不吸引人。

回答by Eenoku

This answer is going to be basically the same, as the one from VonC, just described in a step-by-step manner for less experienced CI users.

这个答案将与 VonC 的答案基本相同，只是为经验不足的 CI 用户逐步描述。

So, let's say, that you have a really cool commit 30728cab and you'd like to make this version of your code a new release...

所以，让我们说，你有一个非常酷的提交 30728cab 并且你想让这个版本的代码成为一个新版本......

1) Create a tag for your commit

1）为你的提交创建一个标签

git tag -a MY_TAG_NAME 30728cab

After this command you'll be asked to fill in a description, just like when you're committing new changes to your code.

执行此命令后，系统会要求您填写说明，就像您对代码提交新更改时一样。

2) Push the tag to your remote repository

2) 将标签推送到您的远程存储库

Tag are NOT going to be pushed there automatically with your commits!You need to push them manually to your remote.

标签不会随着您的提交自动推送到那里！您需要手动将它们推送到您的遥控器。

git push REMOTE_REPO_NAME REMOTE_BRANCH_NAME MY_TAG_NAME

3) Upload a file

3）上传文件

Now you can either a) upload a file to the GitLab repository, b) upload it anywhere else and save the link in both cases.

现在，您可以 a) 将文件上传到 GitLab 存储库，b) 将其上传到其他任何位置并在两种情况下保存链接。

WARNING:Files uploaded to the GitLab repository can't be easily deleted then and you can't see their link later!

警告：上传到 GitLab 存储库的文件不能轻易删除，以后你也看不到它们的链接！

While I'm NOT recommending uploading binaries to the repository because of the reason above, you asked for it, so here is the way:

虽然由于上述原因，我不建议将二进制文件上传到存储库，但您要求这样做，因此方法如下：

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"

The private tokencan be created in User settings -> Access tokens.

该私人令牌可以在创建用户设置- >访问令牌。

Also, if you really needed to delete the file, you can export the project, remove manually the folder updatesfrom your downloaded archive, delete the former remote repository and create a new one by importingyour downloaded and modified archive.

此外，如果您确实需要删除文件，您可以导出项目，updates从下载的存档中手动删除文件夹，删除以前的远程存储库并通过导入您下载和修改的存档创建一个新的。

4) Create a release

4）创建发布

Now we can finally tie it all together using Release.

现在我们终于可以使用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"

You can see, that Release is inherently tied with a specific tag, which is subsequently tied to a specific commit. Connection with binaries is then performed simply by providing links to those files.

您可以看到，Release 固有地与特定标签相关联，该标签随后与特定提交相关联。然后只需提供指向这些文件的链接即可执行与二进制文件的连接。

The funny point is, that your descriptionsupports Markdown, but it's really hard to write some larger *.mddocument in such cumbersome one-liner. So I've written a short Bash script, which allows us to write the Markdown file aside and then it reads it and sends it automatically:

有趣的是，您description支持Markdown，但是*.md在如此繁琐的单行中编写一些更大的文档真的很难。所以我写了一个简短的 Bash 脚本，它允许我们将 Markdown 文件放在一边，然后读取它并自动发送：

#!/bin/bash

RELEASE_NAME=""
TAG_NAME=""
PROJECT_ID=""
DESCRIPTION_FILE_PATH=""
PRIVATE_TOKEN=""

if [ "" == "" ]; 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

so you can use it just like

所以你可以像使用它一样

./upload_release.sh MY_RELEASE_NAME MY_TAG_NAME MY_PROJECT_ID MY_MARKDOWN_FILE_PATH MY_PRIVATE_TOKEN

./upload_release.sh MY_RELEASE_NAME MY_TAG_NAME MY_PROJECT_ID MY_MARKDOWN_FILE_PATH MY_PRIVATE_TOKEN

And now that's it! You have your first complete release!

现在就是这样！你有你的第一个完整版本！

Until you realizes, that you've made a terrible typo in the header of your release description...

直到你意识到，你在发布描述的标题中犯了一个可怕的错字......

5) Delete a release (if needed)

5）删除一个版本（如果需要）

Here you're lucky! Unlike uploaded binaries you can delete your releases using the REST API, too!

在这里你很幸运！与上传的二进制文件不同，您也可以使用 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"

And as it is still pretty annoying to type this several times in a row, I've made another Bash script:

由于连续输入几次仍然很烦人，我制作了另一个 Bash 脚本：

#!/bin/bash

PROJECT_ID=
TAG_NAME=
PRIVATE_TOKEN=

if [ "" == "" ]; 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

which can be used like ./delete_release.sh MY_PROJECT_ID MY_TAG_NAME MY_PRIVATE_TOKEN.

可以像./delete_release.sh MY_PROJECT_ID MY_TAG_NAME MY_PRIVATE_TOKEN.

回答by Fikret An?l Haksever

I am using a command line toolI've written in python as a shortcut. Does some steps of the API methods described in previous answers (Upload, Release, Delete Release).

我正在使用我用 python 编写的命令行工具作为快捷方式。之前的答案（上传、发布、删除发布）中描述的 API 方法的一些步骤。

You can check the source codeor just use it yourself.

您可以查看源代码或自行使用。

For even simpler version, if anyone is interested in doing these with python and requests.py; it is pretty trivial.

对于更简单的版本，如果有人有兴趣用 python 和 requests.py 做这些；这很简单。

For Upload

上传

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()

Upload returns a jsonwith the linkand the markdown formatted link. I found markdown formatted link pretty useful for the release description. Since you have to add the link to the description yourself.

上传返回一个带有链接和 Markdown 格式链接的json。我发现 markdown 格式的链接对于发布说明非常有用。由于您必须自己添加链接到描述。

For Creating a Release

用于创建发布

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 is the release.

JSON 响应是发布。

For the other steps basically follow API guidelinesand make the adjustments. All of them are pretty similar.

对于其他步骤，基本上遵循API 指南并进行调整。他们都非常相似。

回答by schmunk

We're using scpto copy files, such as binaries or reports, generated in GitlabCI.

我们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}

回答by volker

Gitlab (server) itself is for git repositories. You are not supposed to store binaries in git. Nexus would here the way to go. You might add a link to nexus in your repositories description or readme file (like you can point there to your jenkins build, too).

Gitlab（服务器）本身用于 git 存储库。你不应该在 git 中存储二进制文件。Nexus 将是您要走的路。您可以在您的存储库描述或自述文件中添加一个指向 nexus 的链接（就像您也可以指向您的 jenkins 构建）。

You might want to take a look into GitLab Continuous Integration which integrates with Gitlab. That seems to be more something like Jenkins. I do not know if it comes with a data storage like Nexus.

您可能想查看与 Gitlab 集成的 GitLab 持续集成。这似乎更像詹金斯。我不知道它是否带有像 Nexus 这样的数据存储。