v0.18 版本包括对 API 密钥处理和使用持续集成时的工作流程的改进。
使用 mix hex.user auth 进行身份验证时，我们现在会生成两个 API 密钥而不是一个。一个密钥未加密，具有读取权限，另一个密钥使用您的本地密码加密，对 API 具有完全的读写权限。Hex 对 API 密钥进行加密是为了安全原因，例如，您无法在没有提供密码的情况下运行 mix hex.publish，但这意味着像 mix hex.search 这样的命令需要密码，这感觉没有必要。现在，不会对不进行任何更改的命令要求密码。
此外，我们生成了一个密钥，该密钥可以访问您组织的所有存储库，而不是每个存储库一个密钥。它还有额外的好处，即如果您被添加到新的组织，则无需重新进行身份验证。
我们还添加了对直接由组织拥有而不是特定用户拥有的密钥的支持，这些密钥可以通过 mix hex.organization 和 组织仪表板 访问。这在为 CI 环境生成密钥时非常有用，以前使用个人密钥时，人员离开组织或吊销密钥可能会对 CI 工作流程产生负面影响。
引入了 HEX_API_KEY 环境变量，以便运行需要身份验证的命令，而无需使用具有用户输入提示的 mix hex.user auth 手动进行身份验证。使用 HEX_API_KEY 设置的密钥可以使用 mix hex.user key generate 或 mix hex.organization key ORGANIZATION generate 生成。它还使您能够在不提示输入密码的情况下运行诸如 mix hex.publish 这样的命令。
通过将 --yes 标志传递给 mix hex.publish，您可以发布您的包（以及 HEX_API_KEY），而没有任何确认提示。这允许您将包发布为 CI 构建过程的一部分。请记住，这将发布包，即使 Hex 中有警告，并且您无法在发布之前检查编译后的包内容，因此您应该谨慎使用此选项。
此版本侧重于在 CI 环境中工作和运行需要身份验证的命令时的工作流程改进。拥有私有包的用户将具有更好的安全性，因为他们可以使用专门的密钥来为其组织。
将功能从 Hex 客户端迁移到 hex_core 的工作正在进行。hex_core 是由 Hex 团队成员 Wojtek Mach 启动的一项工作，其目的是将创建 Hex 包管理器客户端所需的核心功能迁移到一个通用的 Erlang 库。这减少了重复的开发工作，并将使诸如 rebar3 和 erlang.mk 这样的工具能够与 Hex 的最新更改和改进保持同步。
核心团队的下一步是发布私有 HexDocs 和为组织添加年度计费。Hex v0.18.0 的完整更改列表可以在我们的 发行说明 中找到。