本文档介绍了用于导入外部依赖项的政策。
必须使用 JIRI 清单将所有外部依赖项固定到特定的 git 哈希或 CIPD 软件包版本。此政策可防止其他代码库中的更改破坏 Fuchsia build。
托管在外部服务器上的代码库（例如具有
chromium.googlesource.com）必须在 JIRI 清单中使用<project>元素，该元素具有如下形式的name属性：external/<hostname>/path/to/repo。此命名方案可确保对同一外部代码库的多个引用具有一致的清单值。包含非标准许可或版权所有者的依赖项必须在 JIRI 清单中使用
<project>元素，该元素具有以third_party/开头的path属性。Fuchsia 针对源代码依赖项提供单一版本政策。具体而言，同一段源代码最多只能导入一次，且依赖于该代码的所有内容都必须使用同一版本的代码。预构建的依赖项不受单一版本政策的约束。
运维模式
源代码依赖项以以下两种模式之一运行：
跟踪上游。当代码库跟踪上游时，Fuchsia 项目不是该代码库中代码的可信来源。相反，我们会定期合并来自上游仓库的更新版本代码，这些上游仓库通常由另一团队（例如另一个开源项目）控制。
跟踪上游时，我们通常会在
third_party目录中使用与上游项目相同的名称创建代码库的镜像，以确保 Fuchsia build 的代码可用性。main分支应指向 Fuchsia 使用的引用（通常是版本标记）。上游仓库中存在的分支存在于我们的镜像中，前缀为upstream/（例如foo会变为upstream/foo）。对代码的任何本地修改（例如，与 build 或平台集成）都应位于
main分支中。提取上游更改时，我们会将main分支与上游合并，以使main分支同时包含更新后的上游代码和本地修改。在 Fuchsia 的说法中，跟踪上游的第三方代码库不会被视为“分支”。
可信来源。当代码库是可靠来源时，Fuchsia 项目会控制代码库中的代码。源自 Fuchsia 项目的项目在此模式下运行（即，因为没有可跟踪的上游项目），但有时我们会使用其他项目作为代码库的起点，并为原始项目创建分支。为现有项目创建分支时，我们会为项目选择新名称以避免混淆。
作为可靠来源的代码库可能位于
third_party目录中，也可能不在third_party目录中，具体取决于其许可（例如，因为我们使用具有非标准许可的项目作为起点）。