github 运行python_使用 Github Actions进行无服务器python部署

Python部落(python.freelycode.com)组织翻译，禁止转载，欢迎转发。

Github Actions简介

Github Actions是一个针对Github上因果关系的API，它于2019年11月13日正式上线。Actions允许你触发一个工作流来响应许多不同的事件。虽然我认为它通常用于CI/CD管道，但它也可以用于其他自动化任务，比如设置一个定时任务来自动清除项目中的陈旧问题。关于Github Actions最酷的一点就是操作市场。在撰写本文时，它已经有近2000个预构建的操作可以供你将其插入到你的工作流中并使用。像配置AWS凭据之类有用的事情都可以作为操作使用，这样你就不必自己构建所有东西了。

Github Actions对于业余项目的CI/CD解决方案来说是一个不错的选择。正如他们的定价页面所示(到2021年1月19日为止)，他们有一个很好的免费层，可以让你在你的任何存储库上使用它，包括私人存储库，而不像比较流行的替代品那样，比如Travis。

你好, Actions

在深入研究我为我的无服务器应用程序构建的工作流之前，让我们先从一个简单的示例开始。如下所示，工作流文件被存储在.github/workflows/路径下的github仓库。我们把它命名为.github/workflows/test_ci.yml:

任何合并事件都会触发此工作流。你只需要将它运行在某些分支(比如主分支)的合并上来得到更多具体的细节：

或在使用全局模式匹配修改某些文件时：

这个工作流有一个任务，即build。如果需要，你可以添加更多的任务，这些任务会在默认情况下并行运行。我们的build任务将在ubuntu上运行，它是Github托管的运行系统之一。

对于我们任务中的第一个step，我们利用Github的预构建的checkout操作，它会为ref/SHA拉取一个我们存储库的副本，从而触发工作流。运行此步骤后，当前工作目录将位于存储库的根目录。

最后，这里有两个示例步骤向你展示如何使用操作系统的shell运行命令行程序。需要注意的是，每个run关键字表示运行环境中的一个新进程和shell，因此诸如环境变量或局部定义的变量之类的东西不会在各个运行之间持续存在。对于多行命令，每一行都会在同一个shell中运行，因此，如果你执行:

和预期的一样，输出将是bar。

Zappa 部署

我目前正在使用Zappa来管理一套lambda函数，这些函数运行在Amazon Web Services (AWS)上，以支持我构建的一个slack应用程序:domi。如果你不熟悉Zappa，它极大地简化了使用Python运行时创建、部署和更新lambda函数的过程。你可以从zappa博客或我在多伦多Python大会上的演讲幻灯片中了解更多信息。

说到CI/CD管道，我有两个简单的要求:

使用pytest运行一套测试

将我的代码重新部署到我为项目运行的所有 lambda函数(请查看之前的博文来获取这些不同的函数的详细信息)

我希望测试套件(CI部分)在我们每次向主服务器发送合并请求时运行，而部署工作流(CD部分)在每一个提交被推给主服务器后运行。

合并请求工作流

让我们从“合并请求工作流”开始。我们将在修改特定文件集的任何合并请求进入主分支时触发这个工作流。对于这个项目，我想要该工作流在以下任何文件被修改时运行：

domi目录中的任何文件(所有应用程序代码都在其中)

zappa设置文件

Pipfile 或 Pipfile.lock

就任务而言，我只需要一个运行测试套件的任务。我们将首先使用两个预构建的操作，checkout操作(上面已经讨论过)和setup-python操作，该操作将设置我们任务的其余步骤使用Python 3.7。

接下来，我们将安装libpq-dev(这是psycopg2库的一个要求)和pipenv(我正在使用它来管理虚拟环境)。

对于某些项目，下载所有依赖项并创建一个新的虚拟环境可能是一个非常耗时的步骤。幸运的是，Github引入了缓存功能和一个相关的缓存操作，它们可以让我们在依赖项没有改变的情况下在各个运行之中重用我们的虚拟环境。这是通过将整个~/.local/share/virtualenvs目录和子目录的副本保存到缓存来实现的。每个缓存关联一个唯一的密钥。该密钥将基于任务使用的当前操作系统，以及目录中所有pipenv锁文件的哈希。

每次任务运行时，该操作将基于当前运行的OS和Pipfile来计算缓存key，并查看该密钥是否有相应的缓存。如果此密钥对应的缓存存在，该操作将把此缓存的内容复制到~/.local/share/virtualenvs，这样我们就不必重新创建虚拟环境。

接下来，我们将创建我们的虚拟环境并使用pipenv安装所有的依赖项。我们只在缓存缺失时运行此步骤。

你的任务第一次在一个合并请求上运行时，将导致缓存缺失，因为虚拟环境还没有被创建。

对于给定PR上的工作流的所有连续调用，你将命中该缓存并跳过费时的“安装依赖项”步骤(假设你在连续提交中没有更改任何需求)。

创建了虚拟环境之后，我们就可以运行代码质量检查和测试。秘密就可以像这里讨论的那样被上传到你的存储库，并作为环境变量填充，这些环境变量可以在run shell中通过env参数访问。

把所有东西放在一起之后，.github/workflows/pr.yml文件目前看起来就像这样：

主工作流

“主工作流”负责在任何提交到达主分支后将新代码部署到AWS。我们将重用上面合并请求工作流中的大部分配置，并且只添加几个新组件。第一步是配置我们的AWS凭据，以便我们的工作流可以将代码部署到AWS。对于大多数用例，你可以只利用我上面提到的预构建操作:aws-actions/configure-aws-credentials。

然而，我目前使用的是两个不同的AWS账户(其中一个账户超出了免费期，所以我开了另一个账户，别告诉Jeff)，并且上面的操作不支持多个IAM用户配置文件，所以我使用AWS CLI手动地配置了用户配置文件和凭据。

接下来，我们可以运行一个简单的zappa update --all命令来更新我们所有的lambda函数。

为了得到构建状态的通知，我利用了另一个预构建的Slack操作，即8398a7/action-slack来发送通知。

这些通知充满了有用的链接，比如提交消息、链接和到操作的工作流的链接。

将所有东西整合在一起之后，.github/worksflows/master.yml工作流文件看起来是这样的:

总结

Github Actions真的很容易上手和运行，即使对于没有正规的计算机科学教育或开发背景的人来说也是如此，这要归功于它们出色的文档。与Github的直接集成，很棒的免费层次性定价，以及免费的库、预构建的操作，将使这一特性成为我未来所有项目的一个解决方案。

资源https://help.github.com/en/actions

https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/

https://medium.com/@vanflymen/blazing-fast-ci-with-github-actions-poetry-black-and-pytest-9e74299dd4a5英文原文：https://ianwhitestone.work/AWS-Serverless-Deployments-With-Github-Actions/

译者：测试