这是 Github Action Advent Calendar 的第十八天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
当你构建一个执行 验证 pull request 或 持续集成构建(build) 的工作流时，你常常希望获取构建输出的内容，并且将这些输出内容保存，以便在之后使用它。
有时候，创建一个包 ，并发布这个包到一个类似 Github Package 的包仓库/注册中心是有意义的。但是，有时您只希望将它存储为构建输出的一部分，以便之后能够下载。Github Actions 允许你上传 aritfacts 作为你工作流的一部分，以后您可以下载它。
这是 Github Action Advent Calendar 的第十七天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
如果您已经配置了一个包含多个任务(jobs) 的工作流 — 无论是 基于矩阵的工作流 还是您才刚刚单独定义的任务— 这些任务都是独立于其他任务而并行运行的。通常来说，这是理想的。您的任务会在机器能够执行它们的时候尽快运行。
但是，有些时候您可能希望可以配置依赖于其他任务的任务。例如，你可能有一些想要测试的服务。但是为了省钱，您只希望在您真正运行测试的时候再运行这些服务。所以，您可能需要一个启动您的服务的任务，一个运行测试的任务，还有一个停止服务的任务。
这是 Github Action Advent Calendar 的第十六天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
昨天，我们研究了我们如何在一个工作流的 steps 中 设置自定义的数据 ，以供后续的 steps 使用。我们通过将数据添加到 env context 中来实现这一点，env context 是一个属性包，您可以对其进行读写。
但是，您没有必要限制您自己只在 steps 中使用 env context 。您也可以在您的工作流(workflow) 内部中使用 env context ，比如基于您在之前的 steps 中设定的数据(环境变量)设置一些条件。
这是我的 Github Action Advent Calendar 的第十五天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
在 Github Action 的一个 job 中，你可以拥有多个 step ，一个接一个的运行。每个 step 都可以唤起一个 action — 如 获取您仓库中的代码 或 安装一个特定的 Node.js 版本 — 或者它可以仅仅只是一个 run step，仅仅运行您提供的脚本。
但是您通常希望与您之前运行的 step 进行交互 — 例如，您可能想要运行一个更新您的软件版本号的 step，为发布这个软件做好准备。然后，您可能希望在实际的发布 step 中使用这个版本号。
然而，您如何来回获取这个数据呢？
这是我的 Github Action Advent Calendar 的第十四天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
Github Action 拥有许多本身就很强大的组件，而当你将他们组合在一起使用时，事情才变得真正地强大起来。例如：矩阵工作流使你可以轻松地扩展一个简单的工作流为多个不同的 job 。而条件式的执行允许你限制一个 job 中 step 的执行。
这两个特性完美地自然结合在一起
这是我的 Github Action Advent Calendar 的第十三天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
昨天我们了解到，当您运行一个工作流时，可以使用其中大量的数据信息。您可以在 steps 参数中的 run 参数中使用这些数据，并将其与您的构建脚本，部属步骤或者是仓库的自动化操作一起使用。当然您也可以在工作流(workflow) 内部使用它。
而利用这些数据的一个有用的方式就是使用这些数据来有 有条件地运行工作流的 steps。
这是我的 Github Action Advent Calendar 的第十二天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
昨天我们了解到， Github 提供了一些信息供以 Github Action 工作流的运行，它被命名为 GITHUB_TOKEN。但这还不是全部，那么 Github Action 还提供了哪些其他信息给您呢？
实际上，还真的不少。
这是我的 Github Action Advent Calendar 的第十一天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
昨天我们配置了一个基于路径更改而触发的工作流；这个工作流的目标是为了发布文档。如果你仔细观察的话，在这个工作流的底部，我们引用了一个变量。它和我们引用矩阵变量的方式很像，但其实是引用了一个密文 (secret) 。
在部属项目的场景中，您经常需要一些类似 token 和 passowrd 的东西，Github Action 支持它们以 secrets 的方式保存在您的仓库中。
这是我的 Github Action Advent Calendar 的第十天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
在前面可以看到，我们可以基于分支过滤器来限制工作流的运行。对于由 push 或者 pull_request事件触发的工作流 (workflow)，您可以限制它们只能在一个特定的分支 (branch) 被 push ，或者在一个特定的分支上创建 pull request 时，对应的事件才被触发。
这是我的 Github Action Advent Calendar 的第九天的内容，如果您想要了解更多已经发布的 tips 信息，查看此处的 索引
本月至今，我们已经研究了许多场景，这些场景先执行一个构建(build)，再运行一些测试(tests)。这些都是优秀的工作流(workflow) — 因为它们确保了对您的项目的 pull request 是高质量的，以及您的主分支的健康。
但是您通常希望进行下一步的操作，并部属您构建好的某些内容。例如，你可能会想要构建一个容器，在每次主分支有新的内容时将其上传到 Github Packages 上。这可以保证您有一个容器，可以运行和验证每一个修改。