blog
blog copied to clipboard
qiwihui
技术和思考，基于issues
## 使用 diesel 管理数据库变化 diesel 是一个用 rust 写的 ORM 库，支持多种数据库，同时 diesel 提供了对数据库结构的管理功能。我们将使用 diesel 对我们的数据库结构变化进行管理。 首先，安装命令行工具 `diesel_cli`，并初始化数据库设置 ```shell # 安装 diesel_cli，支持 postgres cargo install diesel_cli --no-default-features --features postgres # 设置数据库连接 echo...
## Actix actix 是 Rust 生态中的 Actor 系统。actix-web 是在 actix actor 框架和 Tokio 异步 IO 系统之上构建的高级 Web 框架。 本篇博客实践使用 actix-web 实现一个简单的 todo 应用。基本要求：了解 rust 基本语法，了解一定的 sql 和 docker 知识。 ##...
## 如何获取路径参数 添加根据 id 获取数据操作： ```rust use std::io::{Error, ErrorKind}; // ...省略 pub async fn get_todo(client: &Client, list_id: i32) -> Result { let statement = client .prepare("select * from todo_list where...
## 配置过程 之前部署了 Shadowsocks 和 V2ray 在两台服务器上，最近由于费用增加，于是决定将两个服务合并到同一台服务器上，并保持原来的配置文件不变。此文简单记录。 Shadowsocks 配置了 simple-obfs 浑下，参数为 `obfs=tls`。V2ray 使用 nginx + tls + websocket，并使用letsencrypt自动生成 HTTPS 证书。两个均使用不同的域名访问。 主要的难点在于需要根据不同的域名将流量分发到后端不同的代理上，方法使用 Nginx 基于 SNI 的 4 层转发，即识别 SNI 信息，然后直接转发 TCP/UDP...
很难低估容器在DevOps实践中的重要性。通常，你会将容器部署到生产环境中──因此很自然地开始使用容器进行本地开发，并管理依赖项。我们研究了如何利用它[在容器内部](https://qiwihui.com/qiwihui-blog-88/)进行构建。但是，我们也可以使用[容器服务](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idservices)，将正在运行的容器用作构建和测试工作流程的一部分。 你通常需要运行一些与其他服务（通常是数据库）进行通信的集成测试。你可以通过编写 `docker run` 命令来拉下容器，启动容器并映射必要的端口，从而编写脚本，但这在最佳情况下很烦人。而且，如果你要[在容器中进行构建](https://qiwihui.com/qiwihui-blog-88/)，则自己运行docker会变得非常棘手。 使用容器服务可以使GitHub Actions基础架构为你执行。你只需指定容器和要映射的任何端口，它将在作业开始时启动服务容器，并使该容器可用于作业中的步骤。 ```yml services: redis: image: 'redis:latest' ports: - 6379/tcp ``` 这将启动 `redis:latest` 容器并将容器中的端口6379映射到虚拟机运行程序上的端口。这等同于运行 `docker run redis:latest -p 6379/tcp`，就像你要运行该命令一样，映射到本地运行程序上的端口不是确定性的。GitHub Actions可在job.services上下文中提供此信息。 你可以查看 `${{ job.services.redis.ports[6379] }}` 以标识本地端口号。（就像运行...
昨天，我们研究了如何在工作流运行过程中[上传文件](https://qiwihui.com/qiwihui-blog-101/)，然后手动下载它们。这在许多情况下都非常有用，但是我认为使用文件的更强大的部分是使用工件在不同步骤之间传输文件。 例如：你可能有一个项目，该项目在多个平台上创建二进制文件，将这些二进制文件作为文件上载，然后发布到最后运行作业以将这些不同的二进制文件聚合到一个程序包中。 或者，你可能想散开──拥有一个创建单个文件的作业，然后在不同平台上运行多个作业以测试该文件。 在这里，我有一个测试我的本机代码的工作流程：首先，我构建本机代码测试运行器，该运行器使用 [clar](https://github.com/clar-test/clar) 单元测试框架，以便它编译一个以 `testapp` 命名的包含我所有单元测试的二进制文件。该二进制文件作为名为的文件上传 `tests`。然后，我将创建一个依赖于第一个`build` 作业的矩阵作业。它将使用最新版本的Ubuntu，Debian，CentOS和Alpine建立一个在容器内执行的矩阵。每个作业将下载 `tests` 构建作业中生成的文件，然后将设置 testapp 为可执行文件（因为文件不保留Unix权限），最后运行测试应用程序。 当我运行它时，构建将产生一个文件，并且当该构建完成时，我的测试作业将全部开始，下载该文件，然后运行它。  你可以看到，上传文件对于生成构建输出非常有用，你可以在后续构建步骤中下载和使用这些输出。 原文链接：https://www.edwardthomson.com/blog/github_actions_19_downloading_artifacts.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow me: [@qiwihui](https://github.com/qiwihui) > > Site:...
如果你设置了包含多个作业的工作流程（无论是[基于矩阵的工作流程](https://qiwihui.com/qiwihui-blog-85/)还是只是单独定义了作业），这些作业将彼此独立地并行运行。通常，这是理想的。只要有可用的计算机即可执行你的作业。 但是有时你希望能够设置依赖于其他作业的作业。例如，你可能有一些要测试的服务。但是为了节省成本，你只想在实际运行测试时运行那些服务。因此，你可能想要一个启动服务的作业，一个运行测试的工作业，然后是一个停止服务的作业。 要指定作业之间的依赖关系，可以使用 `needs` 关键字指示哪些作业依赖于其他作业的完成。 现在，这似乎不是一个很好的例子–我们可能不使用单独的作业，而可能只在一个作业中完成了这三个步骤。但是使用作业可以使我们“成长”：实际上，我们可以在一个作业中设置测试基础结构，然后并行运行多个作业以对其进行测试，然后最后运行清理作业。  这样一来，我们就可以在多个平台上并行运行测试作业，并通过设置将这些作业预定下来，然后停止作业。我们可以通过定义我们的安装作业，然后定义依赖于它的许多作业，然后依赖于这些作业的最终的工作。这通常称为“扇出”和“扇入”。 通过此工作流程，我们的设置作业将运行，然后将使用矩阵在Windows，macOS和Linux上运行构建和测试作业，最后，我们将关闭启动的那些测试资源。  你可以通过相互指定作业来轻松地构建高级工作流， `needs` 以指定工作流的依赖关系图。 原文连接：https://www.edwardthomson.com/blog/github_actions_17_dependent_jobs.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow me: [@qiwihui](https://github.com/qiwihui) > > Site: [QIWIHUI](https://qiwihui.com)
当你构建执行pull request验证或持续集成构建的工作流时，你通常希望获取该构建输出并保存它，以便以后使用。有时创建一个软件包并将其发布到[GitHub packages](https://qiwihui.com/qiwihui-blog-92/)之类的软件包仓库中是有意义的 。但是有时你只想将其存储为构建输出的一部分，以后可以下载。GitHub Actions允许你将文件上传为工作流的一部分，以供日后下载。 要将文件作为构建的一部分进行上传，可以使用 [`upload-artifact`](https://github.com/actions/upload-artifact) 操作。你可以指定为其创建文件的路径–你可以指定单个文件或文件夹，以及文件的名称。你指定的路径将以你指定的工件名称存档到一个zip文件中。 例如，我可以构建和测试我的项目，然后创建一个nuget包，最后将该nuget包作为文件上传。 现在，当我的工作流程运行时，我将在该运行的右上角获得一个选项，向我展示我的文件并让我下载它们。  将构建输出作为文件上载可以与包仓库一起使用：我喜欢将CI构建包上载到GitHub packages，并从pull request中创建工件。这使我可以选择在本地运行和测试PR验证构建──我可以将它们作为文件下载──而不会影响我的GitHub Packages帐户。如果你希望选择在本地运行，那很好，即使你很少这样做。 原文连接：https://www.edwardthomson.com/blog/github_actions_18_artifacts.html > GitHub repo: [qiwihui/blog](https://github.com/qiwihui/blog) > > Follow me: [@qiwihui](https://github.com/qiwihui) > > Site: [QIWIHUI](https://qiwihui.com)
昨天，我们研究了如何在工作流步骤之一中[设置自定义数据](https://qiwihui.com/qiwihui-blog-98/)，以便在后续步骤中使用。我们通过向[env上下文](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#contexts)添加数据来做到这一点，它是一个你可以读写的属性包。 但是你不必将自己局限于仅在你的步骤中使用 `env` 上下文。你还可以在工作流本身中使用 `env` 上下文，并根据在先前步骤中设置的数据来[设置条件](https://qiwihui.com/qiwihui-blog-96/)。 例如，你可能有一个每天要运行的工作流，并且你希望对该工作流在星期一的运行方式进行较小的修改。你可以使用 [`schedule` 触发器](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#onschedule)每天运行工作流程。你可以复制该工作流程，并添加只希望在星期一运行的特殊更改。但是，呵呵，维持两个相似但只有一点点不同的工作流程是一个严重的难题。 取而代之的是，你可以查看星期几并在此基础上设置一个环境变量──在这里，我将使用bash语法运行 `date` 命令以打印缩写的星期几，并将其放入我的 `echo` 语句中，将 `DAY_OF_WEEK` 在我们的 `env` 上下文中设置变量 。然后，我将其 `env.DAY_OF_WEEK` 作为后续步骤的条件。 使用此配置，我将每天在世界标准时间05:00运行工作流。与今天一样，在星期一，将运行仅星期一的步骤。  但是在本周的剩余时间里，该步骤将被跳过。  这是另一个很好的例子，说明GitHub Actions如何为你提供简单的原语，你可以将它们组合在一起以创建功能强大的工作流。 原文链接：https://www.edwardthomson.com/blog/github_actions_16_conditionals_with_shared_data.html > GitHub...
在 GitHub Actions 的任务中，你可以有多个步骤 ，一个接一个地运行。每个步骤可能是调用一个操作（例如，[检出存储库中的代码](https://github.com/actions/checkout)或[安装特定版本的Node.js](https://github.com/actions/setup-node)），也可能是一个 `run`，仅运行你提供的脚本的步骤。 但是通常你希望与之前执行的步骤进行交互，例如，你可能希望运行一个步骤来更新软件的版本号，以使其准备好发布。然后，你可能需要在实际的发布步骤中使用该版本号。 但是，如何来回获取这些数据？GitHub Actions在其自己的流程中运行你的每个步骤。这意味着你不能只在一个步骤中设置环境变量，然后在另一步骤中引用它。换句话说，这将无法正常工作： ```yml steps: # 这将 **无效**。这两个 `run` 步骤被编写为 # 作为不同的脚本并由不同的shell运行，因此 # `FOO` 变量将不会在它们之间持久存在。 - run: export FOO=bar - run: echo $FOO ```...