当前位置: 首页 > 知识库问答 >
问题:

Github操作-用于并行图像构建的多个工作流

金钧
2023-03-14

我在GitHub中有一个包含多个服务的monorepo
我想在两个条件下同时构建它们(使用GitHub操作):

  • 标记-使用标记名称构建图像(service-a: v1.0.0
  • 分支main-使用带有缓存的标签最新构建图像。

我找不到如何创建通用工作流和修改参数(如函数)的方法。
我能想到的唯一解决方案是创建一个复合操作,如下所示:

runs:
  using: "composite"
  steps:
    - uses: actions/checkout@v2
      with:
        lfs: true

    - uses: docker/setup-qemu-action@v1

    - uses: docker/setup-buildx-action@v1

    - uses: docker/login-action@v1
      with:
        registry: ${{ secrets.registry }}
        username: ${{ secrets.username }}
        password: ${{ secrets.password }}

    - name: Environment details
      id: github_ref
      run: |
        echo ::set-output name=SOURCE_TAG::${GITHUB_REF#refs/tags/}

    - uses: docker/build-push-action@v2
      with:
        context: ${{ inputs.context }}
        push: true
        file: ${{ inputs.dockerfile }}
        tags: ${{ secrets.registry }}/${{ inputs.image }}:{{ steps.github_ref.outputs.SOURCE_TAG }}
        build-args: ${{ inputs.build-args }}
        cache-from: ${{ inputs.cache-from }}
        cache-to: ${{ inputs.cache-to }}

但现在我遇到了一个问题,需要在两个工作流中指定服务的所有作业,例如:

主要分支机构工作流:

on:
  push:
    branches:
      - main

jobs:
  build-service-a:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    steps:
      - uses: ./.github/actions/build-image
        with:
          dockerfile: service-a/Dockerfile
          context: .
          image: service-a

  build-service-b:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    steps:
      - uses: ./.github/actions/build-image
        with:
          dockerfile: service-b/Dockerfile
          context: .
          image: service-b

标记分支工作流:


on:
  release:
    types:
      - created

jobs:
  build-service-a:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    steps:
      - uses: ./.github/actions/build-image
        with:
          dockerfile: service-a/Dockerfile
          context: .
          image: service-a
          cache-to: ...
          cache-from: ...

  build-service-b:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    steps:
      - uses: ./.github/actions/build-image
        with:
          dockerfile: service-b/Dockerfile
          context: .
          image: service-b
          cache-to: ...
          cache-from: ...

如您所见,我有多个副本:

  • 由于标签和分支主目录的运行策略,工作流被复制
  • 复合动作的执行有很多样板

减少这些重复并重用构建操作的最佳方法是什么?(并行)

共有1个答案

傅正豪
2023-03-14

如果使用矩阵,您将获得略好的结果:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
       include:
         - dockerfile: service-a/Dockerfile
           image: "service-a"
           cache-to: ...
           cache-from: ...
         - dockerfile: service-b/Dockerfile
           image: "service-b"
           cache-to: ...
           cache-from: ...
    steps:
      - uses: ./.github/actions/build-image
        with:
          dockerfile: ${{ matrix.dockerfile }}
          context: .
          image: : ${{ matrix.image }}
          cache-to: ${{ matrix.cache-to}}
          cache-from: ${{ matrix.cache-from}}

这不会将您从中解救出来,因为标记和分支主运行策略会复制工作流,但会减少工作流中的双模板代码。

 类似资料:
  • 我的用例是,我希望每个构建/运行的工件都有一个唯一的版本号。对于CircleCI、Travis等当前工具,有一个可用的构建编号,它基本上是一个不断上升的计数器。因此,我可以创建版本字符串,如0.1.0-27。即使对于相同的提交,此计数器也会每次增加。 如何使用GitHub Actions做类似的事情?Github操作只提供GITHUB_SHA和GITHUB_REF。

  • 我有以下GitHub操作的文件(删除了一些代码,以便更容易理解这个问题): 我经历了以下步骤: 在分支上进行一些提交,并推动这些更改 我期望GitHub Actions在第2项之后运行测试和部署阶段作业。但是相反,它只是再次运行,而没有运行。 如上所述,即使在推送到之后,它仍然在分支上运行,而不是在分支上运行。我有点假设这可能是由于一些奇怪的行为与快进合并。但是GitHub显然意识到我推动了,因为

  • 我正在尝试通过 Jenkins 构建 Windows 安装程序。 我有许多jenkins项目,它们构建单个模块,然后通过s3工件插件将这些工件保存在s3中。 我想并行运行这些项目,并将项目复制到最终的“构建安装程序”作业中,该作业采用所有这些并构建安装程序映像。我想出了如何与 jenkins 工作流并行运行作业,但我不知道在哪里查找如何提取作业结果详细信息,确保它们都是相同的变更集并将其传递给“构

  • 我最近将我的项目与github操作连接起来,用于持续集成。我创建了两个独立的作业:第一个检查拉取请求中的代码是否被我们的linter接受,第二个检查代码是否通过测试套件。我喜欢有两个这样的工作在Github网页上显示为两个单独的选中标记,用于拉取请求: 我现在遇到的问题是工作流YAML文件中有一些重复的代码:前3个步骤,安装Lua和Luarock。不仅维护起来很烦人,而且运行两次相同的操作也会浪费

  • 我正在为项目存储库设置Github操作。 工作流程包括以下步骤: 构建docker形象 将图像推送到容器注册表中 推出Kubernetes部署 然而,我有两种不同的Kubernetes部署:一种用于开发,另一种用于生产。因此,我还有两个Github操作工作流。 每次推送提交时,都会触发Github开发操作工作流: 但我不希望在我的生产工作流程中出现这种情况。我需要一个手动触发器,比如“发送到生产”

  • PFMERGE destkey sourcekey [sourcekey ...] 将多个 HyperLogLog 合并为一个 HyperLogLog ,合并后的 HyperLogLog 的基数估算值是通过对所有给定 HyperLogLog 进行并集计算得出的。 命令的复杂度为 O(N) , 其中 N 为被合并的 HyperLogLog 数量, 不过这个命令的常数复杂度比较高。