捕获 Git scm 信息¶
在配方中处理源代码有 2 种主要策略
第三方代码:当
conanfile.py配方打包第三方代码(如开源库)时,通常最好使用source()方法来下载或克隆该库的源代码。这是 ConanCenter 仓库遵循的方法。您自己的代码:当
conanfile.py配方打包您自己的代码时,通常最好将conanfile.py放在与源代码相同的仓库中。然后,有两种方法可以实现可重复性使用
exports_sources(或export_source()方法)来捕获源代码的副本,并将其与配方一起包含在 Conan 包中。这非常简单实用,建议在大多数情况下使用。对于无法将源代码与 Conan 配方一起存储的情况,例如当包要被用于不应该访问源代码的人时,那么当前的 scm 捕获 方法将是最佳选择。
在 scm 捕获 方法中,不是捕获代码本身的副本,而是捕获该代码的“坐标”信息。对于 Git 来说,就是 url(仓库地址)和 commit(提交哈希)。如果配方需要从源代码构建,它将使用这些信息来获取克隆,如果尝试构建的用户没有授权,则该过程将失败。他们仍然可以使用我们分发的预编译二进制文件,但不能从源代码构建或访问代码。
让我们通过一个例子来看看它是如何工作的。请先克隆源代码以重现此项目。您可以在 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
让我们逐步解释正在发生的事情
当配方导出到 Conan 缓存时,
export()方法会执行git.coordinates_to_conandata(),它会将 Git URL 和提交信息存储在conandata.yml文件中,方法是内部调用git.get_url_and_commit()。有关这些方法的更多信息,请参阅 Git 参考。这会获取指向本地
<local-path>/capture_scm的仓库 URL 和提交8e8764c40bebabbe3ec57f9a0816a2c8e691f559它警告说,一旦将包上传到服务器并在其他计算机上尝试从源代码构建,这些信息将 不足以 重新构建此配方,因为其他计算机不包含
<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() 可能会引发错误,并要求提交更改。如果需要多个提交,建议在推送到上游仓库之前将这些提交合并。
如果我们现在执行第二个 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() 方法,默认情况下它会
如果仓库是脏的,它将引发异常
如果仓库不是脏的,但提交在远程仓库中不存在,它会发出警告,但会将本地文件夹作为仓库
url返回。这样,可以在无需将其推送到服务器的情况下测试本地提交。core.scm:local_url=allow可以消除警告,而core.scm:local_url=block将立即引发错误:后者可以在 CI 场景中快速失败并保存一个稍后在conan upload中将被阻止的构建。使用本地提交构建的包,如果尝试使用
conan upload上传到服务器,将会失败,因为这些本地提交不在服务器上,因此包可能无法重现。可以通过设置core.scm:local_url=allow来避免此上传错误。如果仓库不是脏的,并且提交存在于服务器上,它将返回远程 URL 和提交。
凭据管理¶
在上面的示例中,不需要凭据,因为我们的本地仓库不需要它们。但在实际场景中,可能需要凭据。
重要的一点是 git.get_url_and_commit() 将捕获 origin 远程仓库的 URL。出于多种原因,此 URL 不应编码令牌、用户或密码。首先,这将使该过程不可重复,不同的构建、不同的用户将获得不同的 URL,从而获得不同的配方版本。 url 应该始终相同。推荐的方法是以正交的方式管理凭据,例如使用 ssh 密钥。提供的示例包含一个 Github 操作,可以做到这一点
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操作将ssh-key作为git@接收检出,而不是httpswebfactory/ssh-agent@v0.7.0操作负责确保 ssh 密钥在以下任务的执行期间也被激活,而不仅仅是在检出期间。需要在 Github 界面中设置
SSH_PRIVATE_KEY密钥,以及仓库的deploy key(ssh 密钥的私钥和公钥部分)
这样,就可以完全分离配方功能的身份验证和凭据,而无需冒任何泄露凭据的风险。
注意
最佳实践
不要使用在 URL 中编码信息的身份验证机制。这很危险,很容易在日志中泄露凭据。建议使用系统机制,如 ssh 密钥。
执行
conan create不建议用于本地开发,而是运行conan install并本地构建,以避免过多的不必要的提交。只有当一切都在本地工作时,才开始检查conan create流程。