社区开发堆栈¶
架构¶
如概述中所述，GalaxyNG 被视为 pulp 插件。与更普通的 django 应用程序相反，pulp 插件是 pulpcore django 应用程序的扩展。大多数插件应用程序代码都在扩展或使用 pulp 的底层原语，例如“分发”、“存储库”和“内容”。
各个项目的治理越来越倾向于在 pulp_ansible 存储库中编写更少的代码，而在 galaxy_ng 存储库中编写更多的代码。pulp_ansible 存储库中的代码足够通用，不仅可用于 GalaxyNG，还可作为 Red Hat Satellite 产品中的组件。GalaxyNG 正在慢慢变成一个“集成项目”，而不是一个具有独特功能的项目。在 api/v1 代码库中，这种代码编写模式略有不同，因为 pulp_ansible 的实现与 galaxy 索引的许多角色不兼容。
作为有希望的贡献者，您可能需要首先弄清楚在哪里为新功能或错误修复编写代码。一般指导原则是，任何针对 api/v3 的新增强功能都应在 pulp_ansible 项目中开始。任何针对 api/v1 的内容都在 galaxy_ng 项目中。如果您不确定或无法弄清楚代码应该在哪里，请在 Ansible 论坛上联系我们，我们将帮助您指导。
服务¶
- api 服务器
- 工作进程
- 内容应用
- postgres
相关项目¶
- https://github.com/ansible/galaxy_ng
- https://github.com/ansible/ansible-hub-ui
- https://github.com/pulp/pulp_ansible
- https://github.com/pulp/pulp_container
- https://github.com/pulp/pulpcore
api/v1¶
位于 https://github.com/ansible/galaxy_ng/tree/master/galaxy_ng/app/api/v1
v1 api 在 GalaxyNG 中从头开始重新实现，作为简单的 django 模型、视图、序列化器和过滤器集。此 api 版本允许以与 galaxy 中处理角色的相同概念方式从 github 导入和索引角色。两个模型构成了 api/v1 在底层工作方式的大部分：“LegacyRole”和“LegacyNamespace”。
api/v1 中的访问控制由我们称之为“Legacy Namespace”的模型控制。它们与 api/v3 中找到的命名空间不同，因为那里存在命名限制，这些限制不适合在 galaxy 上创建的许多用户名。每个旧命名空间都有一个“所有者”列表，或者说拥有控制命名空间以添加/删除所有者、上传新角色、删除角色等的 github 用户名。如果社交身份验证处理程序不存在，则会自动创建一个旧命名空间，并为已登录用户设置所有者。
api/v3¶
位于 https://github.com/ansible/galaxy_ng/tree/master/galaxy_ng/app/api/v3
v3 api 100% 专注于集合和集合命名空间。随着时间的推移，v3 api 越来越成为 pulp_ansible 提供的端点的重定向。
对集合的访问控制由 v3 集合命名空间和 pulp 对象级别 RBAC 控制。用户被添加到组，该组通过权限绑定到命名空间。对于社区实例，组和权限绑定由社交身份验证处理程序自动处理。
OCI Env¶
社区配置文件仅通过 oci-env 项目支持。不再支持使用项目根目录中的“compose”脚本的“旧”开发堆栈，并将在不久的将来删除。
要开始使用，建议创建一个新的顶级目录来存储您的各种检出。
/src
`- oci_env
`- galaxy_ng
`- ansible-hub-ui
将三个项目克隆到 src 目录中。
cd src
git clone https://github.com/pulp/oci_env
git clone https://github.com/ansible/galaxy_ng
git clone https://github.com/ansible/ansible-hub-ui
在 src 目录中创建一个虚拟环境
cd src
python -m venv venv
安装 oci-env 客户端
cd src
source venv/bin/activate
cd oci_env
pip install -e client
启动堆栈构建和启动
cd src/galaxy_ng
make oci/community
现在可以通过 http://localhost:5001 访问 api。makefile 目标创建了几个测试用户，即用于主要超级用户的 admin:admin。这纯粹是一个没有 UI 的 API 堆栈。这使得测试和使用 github 用户变得困难，因此请参阅下一节关于添加 UI 的内容。
React.js UI¶
要连接到 UI，默认地址是 http://localhost:8002。如果启用了社交身份验证，如果您点击页面右上角的“登录”链接，您将被强制通过 Github 进行身份验证。后端配置中存在 SOCIAL_AUTH_GITHUB_KEY 和 SOCIAL_AUTH_GITHUB_SECRET 会触发 dynaconf 为 UI 读取的外部身份验证设置功能标志，并相应地更改登录链接。如果您想绕过 github 并使用本地 django 用户，请直接访问 http://localhost:8002/ui/login url 并以该方式登录。
直接启动¶
对于 UI 上的开发工作，最简单的方法是在 compose 堆栈之外启动 webpack 开发服务器。默认情况下，npm start 脚本和配置会将 api 调用重定向到 http://localhost:5001，因此无需进行任何黑客操作即可使其在本地工作。
- 安装 NVM 以轻松管理 node.js 版本。
- 使用 NVM 安装并将版本设置为 18：
nvm install 18， - 将 ansible-hub-ui 仓库克隆到所需位置。
- 从检出位置，运行
npm install。 - 从检出位置，运行
npm run start-community。
配置¶
galaxy_ng 项目是一个高度可配置的应用程序，但只能在启动时配置。应用程序的几乎所有行为都受环境变量和静态 settings.py 文件的影响，这些文件由 django 和 dynaconf 读取。目前这些设置都不在数据库中，因此它们只能在应用程序启动之前声明。如果您在启动堆栈后更改任何内容，建议完全销毁堆栈，擦除所有 docker 映像并从头开始启动。
社区特定设置位于 galaxy_ng/profiles/community/pulp_config.env 中
- 注释掉
SOCIAL_AUTH_GITHUB_BASE_URL行 - 添加
PULP_SOCIAL_AUTH_GITHUB_KEY=<value> - 添加
PULP_SOCIAL_AUTH_GITHUB_SECRET=<value>
github 密钥和秘密是通过在 github.com 上您的用户开发者设置下配置 oauth 帐户来提供的。oauth 应用程序配置需要具有有效且可解析的主页 url，并且回调 url 应为具有 "/complete/github/" 作为路径的相同主机。对于本地测试，您可以使用 http://localhost:8002 作为基本 url。
测试¶
GalaxyNG 项目是一个“测试驱动开发”(TDD) 项目。我们对 TDD 的解释是，对 master 分支的 -每个- PR -必须- 具有某种测试或测试更改。它可以是单元测试、功能测试或集成测试，但必须编写一些内容。无论 PR 是错误修复还是功能，都必须编写测试。这就是我们如何避免回归，并跟踪新代码如何在具有许多不同可配置行为的非常复杂和分散的架构中工作的方式。
单元测试¶
更多关注点放在了集成测试上，但是项目中也有一些单元测试。compose 堆栈必须正在运行才能启动单元测试，因为它们正在使用 django 和 postgres 以及临时数据库来执行与 sqlite 不兼容的真实 SQL 调用。
要启动单元测试，请执行 make docker/test/unit。可以通过运行 TEST=xyz make docker/test/unit 来选择特定测试。
功能测试¶
Pulp 有一个称为 功能测试的测试概念。这些主要使用一组 fixture、自动生成的 api 客户端和严格的风格来进行集成测试。运行功能测试所需的环境设置有些复杂，因此 GalaxyNG 项目改为编写集成测试。但是，如果您最终为 https://github.com/pulp 中的任何存储库编写补丁，您将被要求编写功能测试。
集成测试¶
GalaxyNG 项目支持名为“Automation HUB”的 Red Hat 产品。由于它是一种产品，因此它有一个正式的 QE 团队使用他们自己围绕 pytest 构建的私有内部框架来测试发布功能。我们决定在集成测试中“左移”，并让开发人员在其 pullrequest (TDD) 中编写集成测试。最初的集成测试批次来自 fork 内部测试，并提取了测试框架中过于复杂或依赖于公司防火墙后系统的元素。自那时以来，测试得到了大幅增长，并涵盖了更大的范围。集成测试的目标是尽可能简单地运行，并且在您真正只需要 pytest、python-requests 和 ansible-core 的意义上是“框架轻量级”的。大多数集成测试都会实例化一个 REST api 客户端，然后该客户端会与 api 通信并断言某些行为，例如返回代码、响应类型/形状和错误。
每个 docker-compose 配置文件在 dev/<配置文件>/ 目录下都有自己的 RUN_INTEGRATION.sh 文件，该文件会设置必要的变量和 pytest 标记，使其适用于该环境。社区脚本 dev/standalone-community/RUN_INTEGRATION.sh 主要只是为 pytest 设置 -m community 参数，以便它只运行那些被标记为社区的测试。一旦你使用适当的配置启动了堆栈，你可以执行 ./dev/standalone-community/RUN_INTEGRATION.sh 来启动测试。通过在命令末尾追加 -k " 可以最容易地调用特定测试。
如果你为社区配置文件编写了新的测试，请为测试函数添加一个 @pytest.mark.community 装饰器。目前，所有与社区相关的测试都在 https://github.com/ansible/galaxy_ng/blob/master/galaxy_ng/tests/integration/api/test_community.py 和 https://github.com/ansible/galaxy_ng/blob/master/galaxy_ng/tests/integration/cli/test_community.py 中。可以根据需要添加其他文件，只要它们具有合适的文件名和相关的 pytest 标记即可。
提交¶
我们对提交消息有严格的检查，以确保正确引用 https://issues.redhat.com，并且所有提交都经过加密签名。为 git 创建 gpg 签名密钥并配置 github 来使用它超出了本文档的范围，但最终结果是您应该能够通过运行以下命令来开始您的提交：
git commit -s -S
消息需要采用以下格式：
<Short commit title>
<Longer commit description and notes>
Issue: AAH-XXX
Signed-off-by: First Last <email@domain>
如果您正在处理一个未在 jira 工单中跟踪的错误或功能，则可以使用“No-Issue”代替“Issue: AAH-XXX”。如果您正在处理 jira 工单，则需要在 CHANGES 文件夹中创建一个合适的更改日志文件。