多个职位

mstmahmuda11121

般来说，这正是我们想要的行为 - 我们只是确保构建是可重现的，并且不会被以前版本的任何“残留物”“污染”。 在一个地方，以前的构建结果会对我们有很大帮助：安装项目的所有依赖项时。最终，这些不会改变，因为它们是从全局依赖存储库（在我们的例子中是 RubyGems）中提取的。在当前配置中，每次构建都会再次发生这种情况，大约需要五分钟。 幸运的是，CircleCI 允许我们在以后的构建中选择性地重用构建的某些结果，并将它们挂载到以后运行的 Docker 容器中。在我们的示例中，用作项目依赖项的 gem 保存到目录中。因此，我们可以扩展我们的配置，以便在解析和安装依赖项后，该目录被写入 CircleCI 缓存中以用于我们的构建，并在将来的构建中再次使用： 这里我们使用文件的校验和作为 CircleCI 存储相应数据的密钥。


由于当依赖项更改时此文件（及其校验和）也会更改，因此我们确保仅当我们从 华侨资料 目中引用完全相同的依赖项时才会使用缓存的值。 需要注意的是，CircleCI 的缓存最多仅保留 15 天。它们可以（并且应该）仅用于需要更有效地进行和优化构建过程的应用程序。在我们的示例中，缺少缓存不会导致错误，而只会增加构建时间，因为所有依赖项现在都必须（再次）完全从其原始源中提取。 多个职位 在构建作业中，我们现在已经成功构建了应用程序或执行了 linter 并运行了单元测试。然而，对于完整的发布来说，最后两个要求仍然缺失：构建 Docker 镜像并将该镜像发布到DockerHub。 为此，我们扩展了 CircleCI 配置并添加了另一个作业： 在工作流程中，我们现在定义在成功执行构建作业后（并且只有此时），publish_container作业才会启动。




使用工作流程中的需求定义，我们指定必须等待构建作业执行。如果我们使用以下配置，两个作业将并行启动和运行： 由于我们要确保仅在所有测试均成功完成的情况下才构建和分发 Docker 映像，因此我们使用require来确定相应的依赖关系。 如果我们现在推送 CircleCI 自动拾取的更改，我们将获得构建作业的以下概述： 图 - 构建作业概述 现在我们看到这两项工作都已按顺序成功完成。 密码和其他敏感数据 现在剩下的就是最后一步：将我们的 Docker 镜像上传到 DockerHub 注册表。但在进行更新之前，必须使用 DockerHub 访问数据进行登录。当然，我们不想将这些访问数据硬编码存储在 CircleCI 配置中，而是在外部定义它们。 CircleCI 提供了通过 CircleCI UI 为每个项目定义环境变量列表的选项。然后可以在作业（或步骤）中读取和使用这些环境变量。