捕获 Git SCM 信息¶
在 recipes 中处理源代码主要有两种策略
第三方代码:当
conanfile.py
recipe 在打包第三方代码(例如开源库)时,通常最好使用source()
方法来下载或克隆该库的源代码。这是conan-center-index
仓库为 ConanCenter 遵循的方法。您自己的代码:当
conanfile.py
recipe 在打包您自己的代码时,通常最好将conanfile.py
与源代码放在同一仓库中。然后,有两种实现可复现性的替代方案使用
exports_sources
(或export_source()
方法)来在 Conan 包中与 recipe 一起捕获源代码的副本。这非常简单实用,在大多数情况下都会推荐。在无法将源代码与 Conan recipe 放在一起的情况下,例如当包供完全不应访问源代码的人使用时,那么当前的 SCM 捕获 方法将是可行之道。
在 SCM 捕获 方法中,不是捕获代码本身的副本,而是捕获该代码的“坐标”,在 Git
案例中,是仓库的 url
和 commit
。如果 recipe 需要从源代码构建,它将使用该信息进行克隆,如果尝试此操作的用户未经授权,则过程将失败。他们仍然可以使用我们分发的预编译二进制文件,但无法从源代码构建或访问代码。
让我们通过一个例子来看看它是如何工作的。请先克隆源代码以重新创建此项目。您可以在 GitHub 上的 examples2 仓库中找到它们
$ git clone https://github.com/conan-io/examples2.git
$ cd examples2/examples/tools/scm/git/capture_scm
在那里我们将找到一个小的“hello”项目,其中包含此 conanfile.py
from conan import ConanFile
from conan.tools.cmake import CMake, cmake_layout
from conan.tools.scm import Git
class helloRecipe(ConanFile):
name = "hello"
version = "0.1"
# Binary configuration
settings = "os", "compiler", "build_type", "arch"
options = {"shared": [True, False], "fPIC": [True, False]}
default_options = {"shared": False, "fPIC": True}
generators = "CMakeDeps", "CMakeToolchain"
def export(self):
git = Git(self, self.recipe_folder)
# save the url and commit in conandata.yml
git.coordinates_to_conandata()
def source(self):
# we recover the saved url and commit from conandata.yml and use them to get sources
git = Git(self)
git.checkout_from_conandata_coordinates()
...
我们需要此代码位于其自己的 Git 仓库中,以了解其在实际情况中的工作方式,因此请在 examples2
仓库外部创建一个文件夹,并将当前文件夹的内容复制到其中,然后
$ mkdir /home/myuser/myfolder # or equivalent in other OS
$ cp -R . /home/myuser/myfolder # or equivalent in other OS
$ cd /home/myuser/myfolder # or equivalent in other OS
# Initialize the git repo
$ git init .
$ git add .
$ git commit . -m wip
# Finally create the package
$ conan create .
...
======== Exporting recipe to the cache ========
hello/0.1: Exporting package recipe: /myfolder/conanfile.py
hello/0.1: Calling export()
hello/0.1: RUN: git status . --short --no-branch --untracked-files
hello/0.1: RUN: git rev-list HEAD -n 1 --full-history -- "."
hello/0.1: RUN: git remote -v
hello/0.1: RUN: git branch -r --contains cb7815a58529130b49da952362ce8b28117dee53
hello/0.1: RUN: git fetch origin --dry-run --depth=1 cb7815a58529130b49da952362ce8b28117dee53
hello/0.1: WARN: Current commit cb7815a58529130b49da952362ce8b28117dee53 doesn't exist in remote origin
This revision will not be buildable in other computer
hello/0.1: RUN: git rev-parse --show-toplevel
hello/0.1: Copied 1 '.py' file: conanfile.py
hello/0.1: Copied 1 '.yml' file: conandata.yml
hello/0.1: Exported to cache folder: /.conan2/p/hello237d6f9f65bba/e
...
======== Installing packages ========
hello/0.1: Calling source() in /.conan2/p/hello237d6f9f65bba/s
hello/0.1: Cloning git repo
hello/0.1: RUN: git clone "<hidden>" "."
hello/0.1: Checkout: cb7815a58529130b49da952362ce8b28117dee53
hello/0.1: RUN: git checkout cb7815a58529130b49da952362ce8b28117dee53
让我们一步步解释发生了什么
当 recipe 导出到 Conan 缓存时,
export()
方法执行git.coordinates_to_conandata()
,它通过内部调用git.get_url_and_commit()
将 Git URL 和 commit 存储在conandata.yml
文件中。请参阅 Git 参考 以获取有关这些方法的更多信息。这获取了指向本地
<local-path>/capture_scm
的仓库 URL 和 commit8e8764c40bebabbe3ec57f9a0816a2c8e691f559
它警告说,此信息将 不足以 在包上传到服务器并在其他计算机上尝试从源代码构建后,重新从源代码构建此 recipe,因为其他计算机将不包含
<local-path>/capture_scm
指向的路径。这是预期的,因为我们创建的仓库没有定义任何远程。如果我们的本地克隆定义了远程,并且该远程包含我们正在构建的commit
,那么scm_url
将指向远程仓库,从而使从源代码构建完全可复现。export()
方法将url
和commit
信息存储在conandata.yml
中,以实现未来的可复现性。当包需要从源代码构建并调用
source()
方法时,它会从conandata.yml
文件中恢复信息,在git.checkout_from_conandata_coordinates()
方法中,该方法内部调用git.clone()
以获取源代码。在本例中,它将从<local-path>/capture_scm
中的本地检出克隆,但如果定义了远程,它将从远程克隆。
警告
为了实现可复现性,对于这种 SCM 捕获 技术来说,当前检出不是脏的非常重要。如果它是脏的,将无法保证构建未来的可复现性,因此 git.get_url_and_commit()
可能会引发错误,并需要提交更改。如果需要多个 commit,建议在将更改推送到上游仓库之前合并(squash)这些 commit。
如果我们现在再次执行 conan create .
,由于仓库是脏的,我们将得到
$ conan create .
hello/0.1: Calling export()
ERROR: hello/0.1: Error in export() method, line 19
scm_url, scm_commit = git.get_url_and_commit()
ConanException: Repo is dirty, cannot capture url and commit: .../capture_scm
这可以通过使用 git clean -xdf
清理仓库来解决,或者通过向仓库添加一个包含以下内容(无论如何这可能是一个良好的源代码管理实践)的 .gitignore
文件来解决。
test_package/build
test_package/CMakeUserPresets.json
坐标捕获使用 Git.get_url_and_commit()
方法,默认情况下它会
如果仓库是脏的,它将引发异常
如果仓库不脏,但 commit 在远程不存在,它会发出警告,但会返回本地文件夹作为仓库的
url
。这样,本地 commit 可以在无需推送到服务器的情况下进行测试。core.scm:local_url=allow
可以抑制警告,而core.scm:local_url=block
将立即引发错误:此最后一个值对于 CI 场景很有用,可以快速失败并避免在后续conan upload
中被阻塞的构建。使用本地 commit 构建的包如果尝试使用
conan upload
上传到服务器,则会失败,因为这些本地 commit 不在服务器上,并且因此包可能无法复现。可以通过设置core.scm:local_url=allow
来避免此上传错误。如果仓库不脏,并且 commit 存在于服务器上,它将返回远程 URL 和 commit。
凭据管理¶
在上面的例子中,凭据不是必需的,因为我们的本地仓库不需要它们。但在实际场景中,凭据可能是必需的。
第一个重要的点是 git.get_url_and_commit()
将捕获 origin
远程的 URL。此 URL 不得编码令牌、用户或密码,原因有几个。首先,因为这将导致过程不可重复,并且不同的构建、不同的用户将获得不同的 URL,从而导致不同的 recipe 修订版。url
应该始终相同。推荐的方法是以正交的方式管理凭据,例如使用 SSH 密钥。所提供的示例包含一个 GitHub action 来实现这一点
name: Build "hello" package capturing SCM in Github actions
run-name: ${{ github.actor }} checking hello-ci Git scm capture
on: [push]
jobs:
Build:
runs-on: ubuntu-latest
steps:
- name: Check out repository code
uses: actions/checkout@v3
with:
ssh-key: ${{ secrets.SSH_PRIVATE_KEY }}
- uses: actions/setup-python@v4
with:
python-version: '3.10'
- uses: webfactory/ssh-agent@v0.7.0
with:
ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
- run: pip install conan
- run: conan profile detect
- run: conan create .
此 hello-demo.yml
负责以下事项
检出
actions/checkout@v3
action 接收ssh-key
以git@
而不是https
方式检出webfactory/ssh-agent@v0.7.0
action 确保 SSH 密钥在执行后续任务期间也被激活,而不仅仅在检出期间。必须在 GitHub 界面中设置
SSH_PRIVATE_KEY
密钥,以及仓库的deploy key
(包含 SSH 密钥的私钥和公钥部分)
通过这种方式,可以将身份验证和凭据与 recipe 功能完全分离,而没有任何凭据泄露的风险。
注意
最佳实践
不要使用在 URL 中编码信息的身份验证机制。这有风险,容易在日志中泄露凭据。建议使用 SSH 密钥等系统机制。
执行
conan create
不推荐用于本地开发,而应运行conan install
并在本地构建,以避免过多的不必要 commit。只有当所有内容在本地运行正常时,才应开始检查conan create
流程。