【问题标题】:Copy projects from git submodule to ADO repository将项目从 git 子模块复制到 ADO 存储库
【发布时间】:2020-11-26 10:10:54
【问题描述】:

我有一个 ADO 存储库,其中包含一个 GitHub 存储库作为 git 子模块。

以下是 ADO repo 中的 .csproj 文件示例:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.0.0" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.3" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\..\..\Repositories.ABC\Repositories.ABC.csproj" />
    <ProjectReference Include="..\..\..\Repositories.XYZ\Repositories.XYZ.csproj" />
  </ItemGroup>
</Project>

.csproj 中提到的项目引用 - Respositories.ABC 和 Repositories.XYZ 是 GitHub 存储库(git 子模块)的一部分。 有没有办法将项目 - Respositories.ABC 和 Repositories.XYZ 从 git 子模块复制到指定路径中的 ADO 存储库,这样构建就不会失败?

这是我的项目结构:

这是我的子模块结构:

【问题讨论】:

    标签: git github azure-devops repository git-submodules


    【解决方案1】:

    是的,你应该启用获取submodules

    steps:
    - checkout: self  # self represents the repo where the initial Pipelines YAML file was found
      clean: boolean  # whether to fetch clean each time
      fetchDepth: number  # the depth of commits to ask Git to fetch
      lfs: boolean  # whether to download Git-LFS files
      submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
      path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
      persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch
    

    但是,如果您对子模块使用私有存储库并且不将它们保留在 Azure 存储库中,您可以检查一下 - Alternative to using the Checkout submodules option

    在某些情况下,您不能使用 Checkout 子模块选项。您可能会遇到需要一组不同的凭据才能访问子模块的情况。例如,如果您的主存储库和子模块存储库未存储在同一个 Azure DevOps 组织中,或者您的作业访问令牌无权访问不同项目中的存储库,则可能会发生这种情况。

    如果您不能使用 Checkout submodules 选项,那么您可以改为使用自定义脚本步骤来获取子模块。首先,获取个人访问令牌 (PAT) 并在其前面加上 pat:。接下来,对该前缀字符串进行 base64 编码以创建基本身份验证令牌。最后,将此脚本添加到您的管道中:

    git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Bearer <BASE64_ENCODED_STRING>" submodule update --init --recursive
    

    【讨论】:

    • 谢谢!澄清一下 - 如果我有一个 ADO 存储库,其中包含另一个 ADO 存储库作为 git 子模块,我可以使用你提到的第一步正确吗?
    • 一般来说是的。如果他们在同一个项目上,那么肯定。当无法使用此方法时,可能会出现一些极端情况,但您应该尝试一下。
    • 谢谢!我应该在哪里添加您上面建议的结帐步骤?那是在主 ADO 存储库中的 yaml 文件中还是在子模块中的 yaml 文件中?另外,假设子模块中的项目之一的路径是 /Service/Project/Repositories.XYZ。我应该在结帐步骤中指定什么作为路径?请告诉我。
    • 这应该是您在 YAML 文件中的第一步。默认情况下,它将代码获取到C:\agent\_work\1,但这取决于通常子模块在您的主仓库中的位置。请在结帐后添加此步骤- pwsh: ls '$(System.DefaultWorkingDirectory)',以查看您的根文件夹的外观。
    【解决方案2】:

    有没有办法将项目 - Respositories.ABC 和 Repositories.XYZ 从 git 子模块复制到指定路径中的 ADO 存储库,这样构建就不会失败?

    恐怕没有办法将Github子模块复制到ADO仓库指定路径

    当我们将子模块添加到 ADO 存储库时,它会在 ADO 存储库.gitmodules 和项目名称文件中创建两个文件:

    如果我们检出子模块,git 会根据.gitmodules 中的路径将项目保存到项目名称文件夹中。由于文件.gitmodules 和项目名称文件已添加到源代码管理中,因此默认签出。如果我们要更改路径,我们必须在结帐后手动更改路径。

    为了确保构建成功,我们只需要确保ProjectReference.csproj文件中的路径与repo中的文件结构匹配。

    更新:

    如果你的Cleaner.csproj文件所在的目录层次是这样的Service\Project\Hosts\Cleaner\Function\Cleaner.csproj,那么路径应该是:

    <ProjectReference Include="..\..\..\..\..\crypto-project\Service.xxxx\Repositories.ABC\Repositories.ABC.csproj" />
    

    路径应该是Cleaner.csproj.gitmodules文件的相对位置,一个..\代表上一级目录,..\后面的路径应该是crypto-project+每一级目录文件夹。

    【讨论】:

    • 谢谢!能否请您举例说明 Main.csproj 文件中 ProjectReference 的路径应如何更改?
    • 谢谢!在我的示例中,ADO 存储库中的 .csproj 文件有 2 个项目引用 - Repositories.ABC.csproj 和 Repositories.XYZ.csproj(位于 git 子模块中)。如何更新路径?请举个例子。
    • @user989988,与您在repo中的文件结构相关的路径,请您像我一样在答案中分享repo中的文件结构(包括mian.csproj和Repositories.ABC & Repositories.XYZ文件)。
    • 我更新了项目参考: 但是它给出了错误:无法找到 'C:\Users\\Desktop\submodules\\crypto-project\Service\Project\Repositories.ABC\Repositories 的项目信息。 ABC.csproj'。如果您使用的是 Visual Studio,这可能是因为项目已卸载或不是当前解决方案的一部分,因此请从命令行运行还原。否则,项目文件可能无效或缺少恢复所需的目标。
    • 我明白了——不是在 .csproj 中更新项目引用,是否有不同的方法可以在不使用 git 子模块的情况下成功进行本地构建?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-19
    • 2013-04-30
    • 2019-08-20
    • 2021-10-08
    • 2023-03-09
    • 1970-01-01
    相关资源
    最近更新 更多