【发布时间】:2019-12-21 05:48:13
【问题描述】:
尝试使用 Github 的 beta 操作,我有两份工作,一份负责构建代码,另一份负责部署代码。但是,我似乎无法在部署作业中获得构建工件。
我最近的尝试是为每个作业手动设置具有相同卷的容器映像,根据文档,这应该是解决方案:https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idcontainervolumes
设置容器使用的卷数组。您可以使用卷在服务或作业中的其他步骤之间共享数据。您可以在主机上指定命名 Docker 卷、匿名 Docker 卷或绑定挂载。
工作流程
name: CI
on:
push:
branches:
- master
paths:
- .github/workflows/server.yml
- server/*
jobs:
build:
runs-on: ubuntu-latest
container:
image: docker://node:10
volumes:
- /workspace:/github/workspace
steps:
- uses: actions/checkout@master
- run: yarn install
working-directory: server
- run: yarn build
working-directory: server
- run: yarn test
working-directory: server
- run: ls
working-directory: server
deploy:
needs: build
runs-on: ubuntu-latest
container:
image: docker://google/cloud-sdk:latest
volumes:
- /workspace:/github/workspace
steps:
- uses: actions/checkout@master
- run: ls
working-directory: server
- run: gcloud --version
第一个作业 (build) 有一个 build 目录,但是当第二个作业 (deploy) 运行时它没有并且只包含源代码。
这个项目是一个单声道存储库,我尝试部署的代码位于路径 server 下,因此所有 working-directory 标志。
【问题讨论】:
-
参见 stackoverflow.com/questions/57509118/… - Workflow syntax docs 说“每个作业都在由 runs-on 指定的虚拟环境的新实例中运行。”我的猜测(我不在测试版中,所以我只是在猜测)是您的部署工作要么需要成为
build工作中的一个步骤,要么需要在新的工作中再次重现build步骤容器。 (也许减去yarn test步骤,因为您已经知道它成功了)。 -
你找到答案了吗?我也在试图弄清楚如何做到这一点。从我读过的内容来看,作业应该共享工作区文件系统,但似乎并非如此。
-
@Joseph 不,我只是在运行一项工作并使用自定义 docker 映像。我相信问题出在 GitHub 上,很可能是由于从 HCL 到 YML 语法的转换。奇怪的是,他们计划在 9 月底放弃 HCL,而在工作之间共享人工制品的基本能力还没有起作用。希望在一个月内,它会得到解决。
-
“您可以使用卷在服务或作业中的其他步骤之间共享数据。”这意味着在步骤之间共享单个作业中的数据。它不适用于在步骤或工作流之间共享数据。
标签: github continuous-integration github-actions