是否可以在GitHub操作中的操作之间持久化一个WORKDIR？

Question

今天早上，我发现了我的GitHub Actions BETA版邀请，并开始玩它，目的是迁移一些我目前在CircleCi上运行的简单构建、测试和部署管道。

我仍然在试图理解操作，但我心目中的流程是，在推动之后，工作流中的第一个操作将启动一个Docker容器。在这个容器中，我将运行一些简单的构建过程，比如最小化资产和移除人工制品。接下来的操作将在构建上运行一些测试。管道中的下一个操作将部署到许多环境中的一个，这取决于我推到的分支。

我跟踪了https://developer.github.com/actions/creating-github-actions/creating-a-docker-container/中的文档，并有了一个基本的工作流，它启动一个Docker容器，并在workdir中运行一些构建命令。我还能够从这个Workdir内部运行部署（通过rsync）。

然而，我想把它分成单独的步骤/行动，但我想不出一个方法来实现这一点。

本质上，这将类似于我使用的CircleCI作业/工作流模型。但是，使用Circraeci，第一个作业将运行一个构建，然后在整个工作流的其余部分中保持得到的目录结构，如下所示：

# Persist dist directory
  - persist_to_workspace:
      root: ~/project
      paths:
        - .

所以，我把Circoreci的工作等同于GitHub的行动，这可能是错误的做法？本质上，我试图了解的是，是否可以在第一个操作的Docker容器中持久保存Workdir并使该Workdir可用于后续操作。

这是可能的吗？还是我与我想象的GitHub操作可以做的事情相去甚远？

谢了！

Answer 1

我自己回答这个问题，以防其他人遇到这个问题（和我一样，没有完全阅读文档！）。：O）

这里的文档进行了解释，但实际上，作为操作的一部分启动的任何容器的工作目录都以/github/workspace的形式存在。操作可以修改此工作目录的内容，当容器在工作流期间的后续操作中启动时，这些操作/容器的工作目录将包含工作流中先前进行的修改。

因此，答案是肯定的，位于/GitHub/workspace的Dockerworkdir在整个GitHub操作工作流中的持久化方式类似于它在circoleci工作流中的持久化方式。