一个项目的 Gitlab 工件用于其他项目
Gitlabs artifact of one project used in further projects
问题
- 在 CI 阶段使用 docker 容器时，在项目之间携带工件（jar、class、war）的最佳方式是什么。
让我详细解释一下我的问题，请不要停止阅读... =)
Gitlabs 项目1
- 单元测试
- 等...
- 包
Gitlabs 项目2
- 单元测试
- 等...
- 构建（失败）
- 这里我需要一个在project1中生成的工件（jar）
当前场景/评论
- 我正在使用 dockers 所以在每个 .gitlab-ci.yml 我会有独立的容器
- project1 一切正常
- 如果我在 .gitlab-ci.yml 中使用 "shell" 而不是 dockers，我可以将 project1 中的 jar 文件保留在磁盘中，并在 project2 启动构建时使用
- 今天，当 project1 完成时，我的 trigger on call project2 运行良好
- 我的工件不是 RPM，所以我不会添加到我的存储库中
可能的解决方案
- 我可以提交项目 1 的工件并在需要构建项目 2 时检出
- 我需要研究 gitlabs 的缓存功能是否是为此目的而设计的 (
)
您好，您必须看一下由 morph027 开发的名为 get-last-successful-build-artifact.sh 的脚本。
https://gitlab.com/morph027/gitlab-ci-helpers
此脚本允许下载工件并将其解压缩到项目根目录中。它使用 Gitlab API 检索最新的成功构建并下载相应的工件。您可以组合多个工件并解压缩到任何您想要的地方，只需稍微更新脚本即可。
我目前也在启动 PHP library 来处理构建工件，但它处于非常早期的阶段，目前与 laravel 相关。
目前没有简单的方法来处理项目之间的工件使用，您必须使用该工具构建自己的工件。
我认为使用 shell 执行器不是正确的解决方案，它非常危险，因为您无法验证构建期间使用的服务器上的文件！
希望对您有所帮助:)
太棒了，发现这里引用了我的代码片段 ;)
is it possible to use get-last-successful-build-artifact.sh without private-token (in a world-readable repository)? e.g. to share an artifact download command w/o exposing your token
是的，只需在项目设置 -> 管道 -> 秘密变量中将其添加为 secret variable。
截至撰写本文时，无法仅在管道内跨项目共享工件。参见 https://docs.gitlab.com/ee/ci/yaml/README.html#artifacts
但是，有一个开放功能可以启用此功能，但尚未实现。
https://gitlab.com/gitlab-org/gitlab-ce/issues/14728
在 GitLab silver 和 premium 中，有
$CI_JOB_TOKEN 可用，允许以下 .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
但是，如果您没有白银或更高级别的 gitlab 订阅，但依赖免费套餐，也可以使用 API 和管道触发器。
假设我们有 项目 A 建筑 app.jar 项目 B.
需要它
首先，您需要一个 API 令牌。
转到 Profile settings/Access Tokens 页面创建一个，然后将其作为变量存储在 项目 B 中。在我的示例中，它是 GITLAB_API_TOKEN.
在 项目 B 的 CI / CD 设置中添加一个新触发器，例如“项目 A 已建”。这将为您提供一个可以复制的令牌。
打开项目A的.gitlab-ci.yaml并复制项目B的[=78]中的trigger_build:部分=]/CD设置触发部分.
项目 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"
用该令牌替换 TOKEN（更好的是，将其作为变量存储在 project A 中——然后您需要将其设为 token=${TRIGGER_TOKEN_PROJECT_B} 或其他），以及将 REF_NAME 替换为您的分支（例如 master）。
然后，在项目 B 中，我们可以编写一个仅基于触发器构建并检索工件的部分。
项目 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}"
如果您知道工件路径，那么您可以用它替换${REMOTE_FILENAME}，例如build/app.jar。项目 ID 可以在 CI / CD 设置中找到。
我扩展了 项目 A 中的脚本以传递触发器设置部分中记录的剩余信息：
Add variables[VARIABLE]=VALUE to an API request. Variable values can be used to distinguish between triggered pipelines and normal pipelines.
所以触发器传递了 REMOTE_JOB_ID 和 REMOTE_FILENAME，当然你可以根据需要修改它：
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
arry artifacts (jar, class, war) among projects
这应该是注册表包的用途。
GitLab 13.3（2020 年 8 月），现在免费提供！
Package Registry now available in Core
A year and a half ago, we expanded our support for Java projects and developers by building Maven support directly into GitLab. Our goal was to provide a standardized way to share packages and have version control across projects.
Since then, we’ve invested to build out the Package team further while working with our customers and community to better understand your use cases. We also added support for Node, C#/.NET, C/C++, Python, PHP, and Go developers.
Your increased adoption, usage, and contributions to these features have allowed us to expand our vision to a more comprehensive solution, integrated into our single application, which supports package management for all commonly-used languages and binary formats.
This goal could not have been achieved without the explicit support of the GitLab community.
As part of GitLab’s stewardship promises, we are excited to announce that the basic functionality for each package manager format is now available in the GitLab Core Edition.
This means that if you use npm, Maven, NuGet, Conan, PyPI, Composer or Go modules, you will be able to:
- Use GitLab as a private (or public) package registry
- Authenticate using your GitLab credentials, personal access, or job token
- Publish packages to GitLab
- Install packages from GitLab
- Search for packages hosted on GitLab
- Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
- Ensure that your contributions are available for ALL GitLab users
We look forward to hearing your feedback and continuing to improve these features with all of our users.
See Documentation and Issue.
问题
- 在 CI 阶段使用 docker 容器时，在项目之间携带工件（jar、class、war）的最佳方式是什么。
让我详细解释一下我的问题，请不要停止阅读... =)
Gitlabs 项目1
- 单元测试
- 等...
- 包
Gitlabs 项目2
- 单元测试
- 等...
- 构建（失败）
- 这里我需要一个在project1中生成的工件（jar）
当前场景/评论
- 我正在使用 dockers 所以在每个 .gitlab-ci.yml 我会有独立的容器
- project1 一切正常
- 如果我在 .gitlab-ci.yml 中使用 "shell" 而不是 dockers，我可以将 project1 中的 jar 文件保留在磁盘中，并在 project2 启动构建时使用
- 今天，当 project1 完成时，我的 trigger on call project2 运行良好
- 我的工件不是 RPM，所以我不会添加到我的存储库中
可能的解决方案
- 我可以提交项目 1 的工件并在需要构建项目 2 时检出
- 我需要研究 gitlabs 的缓存功能是否是为此目的而设计的 (
您好，您必须看一下由 morph027 开发的名为 get-last-successful-build-artifact.sh 的脚本。
https://gitlab.com/morph027/gitlab-ci-helpers
此脚本允许下载工件并将其解压缩到项目根目录中。它使用 Gitlab API 检索最新的成功构建并下载相应的工件。您可以组合多个工件并解压缩到任何您想要的地方，只需稍微更新脚本即可。
我目前也在启动 PHP library 来处理构建工件，但它处于非常早期的阶段，目前与 laravel 相关。
目前没有简单的方法来处理项目之间的工件使用，您必须使用该工具构建自己的工件。
我认为使用 shell 执行器不是正确的解决方案，它非常危险，因为您无法验证构建期间使用的服务器上的文件！
希望对您有所帮助:)
太棒了，发现这里引用了我的代码片段 ;)
is it possible to use get-last-successful-build-artifact.sh without private-token (in a world-readable repository)? e.g. to share an artifact download command w/o exposing your token
是的，只需在项目设置 -> 管道 -> 秘密变量中将其添加为 secret variable。
截至撰写本文时，无法仅在管道内跨项目共享工件。参见 https://docs.gitlab.com/ee/ci/yaml/README.html#artifacts
但是，有一个开放功能可以启用此功能，但尚未实现。 https://gitlab.com/gitlab-org/gitlab-ce/issues/14728
在 GitLab silver 和 premium 中，有 $CI_JOB_TOKEN 可用，允许以下 .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
但是，如果您没有白银或更高级别的 gitlab 订阅，但依赖免费套餐，也可以使用 API 和管道触发器。
假设我们有 项目 A 建筑 app.jar 项目 B.
首先，您需要一个 API 令牌。
转到 Profile settings/Access Tokens 页面创建一个，然后将其作为变量存储在 项目 B 中。在我的示例中，它是 GITLAB_API_TOKEN.
在 项目 B 的 CI / CD 设置中添加一个新触发器，例如“项目 A 已建”。这将为您提供一个可以复制的令牌。
打开项目A的.gitlab-ci.yaml并复制项目B的[=78]中的trigger_build:部分=]/CD设置触发部分.
项目 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"
用该令牌替换 TOKEN（更好的是，将其作为变量存储在 project A 中——然后您需要将其设为 token=${TRIGGER_TOKEN_PROJECT_B} 或其他），以及将 REF_NAME 替换为您的分支（例如 master）。
然后，在项目 B 中，我们可以编写一个仅基于触发器构建并检索工件的部分。
项目 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}"
如果您知道工件路径，那么您可以用它替换${REMOTE_FILENAME}，例如build/app.jar。项目 ID 可以在 CI / CD 设置中找到。
我扩展了 项目 A 中的脚本以传递触发器设置部分中记录的剩余信息：
Add
variables[VARIABLE]=VALUEto an API request. Variable values can be used to distinguish between triggered pipelines and normal pipelines.
所以触发器传递了 REMOTE_JOB_ID 和 REMOTE_FILENAME，当然你可以根据需要修改它：
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
arry artifacts (jar, class, war) among projects
这应该是注册表包的用途。
GitLab 13.3（2020 年 8 月），现在免费提供！
Package Registry now available in Core
A year and a half ago, we expanded our support for Java projects and developers by building Maven support directly into GitLab. Our goal was to provide a standardized way to share packages and have version control across projects.
Since then, we’ve invested to build out the Package team further while working with our customers and community to better understand your use cases. We also added support for Node, C#/.NET, C/C++, Python, PHP, and Go developers.
Your increased adoption, usage, and contributions to these features have allowed us to expand our vision to a more comprehensive solution, integrated into our single application, which supports package management for all commonly-used languages and binary formats.
This goal could not have been achieved without the explicit support of the GitLab community.As part of GitLab’s stewardship promises, we are excited to announce that the basic functionality for each package manager format is now available in the GitLab Core Edition.
This means that if you use npm, Maven, NuGet, Conan, PyPI, Composer or Go modules, you will be able to:
- Use GitLab as a private (or public) package registry
- Authenticate using your GitLab credentials, personal access, or job token
- Publish packages to GitLab
- Install packages from GitLab
- Search for packages hosted on GitLab
- Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
- Ensure that your contributions are available for ALL GitLab users
We look forward to hearing your feedback and continuing to improve these features with all of our users.
See Documentation and Issue.