github在线执行

Automation is a powerful tool. It both saves us time and can help reduce human error.

自动化是一个强大的工具。 它既节省了我们的时间，又可以帮助减少人为错误。

But automation can be tough and can sometimes prove to be costly. How can Github Actions help harden our code and give us more time to work on features instead of bugs?

但是自动化可能很困难，有时可能会变得昂贵。 Github Actions如何帮助强化我们的代码并给我们更多的时间来处理功能而不是错误？

• What are Github Actions?

  什么是Github动作？

• What is CI/CD?

  什么是CI / CD？

• What are we going to build?

  我们要建造什么？

• Part 0: Setting up a project

  第0部分：建立项目

• Part 1: Automating tests

  第1部分：自动化测试

• Part 2: Post new pull requests to Slack

  第2部分：将新的拉取请求发布到Slack

什么是Github动作？ (What are Github Actions?)

Actions are a relatively new feature to Github that allow you to set up CI/CD workflows using a configuration file right in your Github repo.

动作是Github的相对较新的功能，它使您可以使用Github存储库中的配置文件来设置CI / CD工作流程。

Previously, if you wanted to set up any kind of automation with tests, builds, or deployments, you would have to look to services like Circle CI and Travis or write your own scripts. But with Actions, you have first class support to powerful tooling to automate your workflow.

以前，如果您想通过测试，构建或部署来设置任何类型的自动化，则必须依靠Circle CI和Travis之类的服务或编写自己的脚本。 但是，有了Actions，您就获得了强大的工具的一流支持，可以自动执行工作流程。

什么是CI / CD？ (What is CI/CD?)

CD/CD stands for Continuous Integration and Continuous Deployment (or can be Continuous Delivery). They're both practices in software development that allow teams to build projects together quickly, efficiently, and ideally with less errors.

CD / CD代表持续集成和持续部署(或可以是持续交付)。 它们都是软件开发中的实践，它们使团队可以快速，高效地构建项目，理想情况下可以减少错误。

Continuous Integration is the idea that as different members of the team work on code on different git branches, the code is merged to a single working branch which is then built and tested with automated workflows. This helps to constantly make sure everyone's code is working properly together and is well-tested.

持续集成的想法是，当团队的不同成员在不同的git分支上处理代码时，代码将合并到单个工作分支中，然后使用自动化工作流程来构建和测试该分支。 这有助于不断确保每个人的代码都能正常工作并经过良好测试。

Continuous Deployment takes this a step further and takes this automation to the deployment level. Where with the CI process, you automate the testing and the building, Continuous Deployment will automate deploying the project to an environment.

连续部署使这一步骤更进一步，并使这种自动化达到了部署级别。 在配置项流程中，您可以自动执行测试和构建，而持续部署可以将项目自动部署到环境中。

The idea is that the code, once through any building and testing processes, is in a deployable state, so it should be able to be deployed.

这个想法是，一旦通过任何构建和测试过程，该代码都处于可部署状态，因此应该能够对其进行部署。

我们要建造什么？ (What are we going to build?)

We're going to tackle two different workflows.

我们将处理两个不同的工作流程。

The first will be to simply run some automated tests that will prevent a pull request from being merged if it is failing. We won't walk through building the tests, but we'll walk through running tests that already exist.

首先将是简单地运行一些自动化测试，以防止在请求失败时合并合并请求。 我们不会逐步构建测试，而是逐步运行已经存在的测试。

In the second part, we'll set up a workflow that sends a message to slack with a link to a pull request whenever a new one is created. This can be super helpful when working on open source projects with a team and you need a way to keep track of requests.

在第二部分中，我们将建立一个工作流，每当创建一个新请求时，该工作流就将一条消息发送给Slack，并带有一个请求请求的链接。 与团队一起从事开源项目时，这可能非常有用，您需要一种跟踪请求的方法。

第0部分：建立项目 (Part 0: Setting up a project)

For this guide, you can really work through any node-based project as long as it has tests you can run for Part 1.

对于本指南，您可以真正完成任何基于节点的项目，只要它具有可以为第1部分运行的测试即可。

If you'd like to follow along with a simpler example that I'll be using, I've set up a new project that you can clone with a single function that has two tests that are able to run and pass.

如果您想跟随一个将要使用的简单示例，我已经建立了一个新项目，您可以使用一个具有两个可以运行和通过测试的功能来克隆该项目。

If you'd like to check out this code to get started, you can run:

如果您想查看此代码以开始使用，可以运行：

git clone --single-branch --branch start git@github.com:colbyfayock/my-github-actions.git

Once you have that cloned locally and have installed the dependencies, you should be able to run the tests and see them pass!

一旦在本地克隆并安装了依赖项，就应该能够运行测试并看到它们通过了！

It should also be noted that you'll be required to have this project added as a new repository on Github in order to follow along.

还应该注意的是，您需要将此项目作为新的存储库添加到Github上，以便进行后续操作。

Follow along with the commit!

跟随提交！

第1部分：自动化测试 (Part 1: Automating tests)

Tests are an important part of any project that allow us to make sure we're not breaking existing code while we work. While they're important, they're also easy to forget about.

测试是任何项目的重要组成部分，可让我们确保工作时不会破坏现有代码。 尽管它们很重要，但也很容易忘记。

We can remove the human nature out of the equation and automate running our tests to make sure we can't proceed without fixing what we broke.

我们可以从等式中消除人性，并自动运行测试以确保在不解决问题的情况下无法继续进行。

步骤1：建立新动作 (Step 1: Creating a new action)

The good news, is Github actually makes it really easy to get this workflow started as it comes as one of their pre-baked options.

好消息是，由于Github是其预先烘焙的选项之一，因此实际上确实很容易启动此工作流程。

We'll start by navigating to the Actions tab on our repository page.

我们将从导航到存储库页面上的“ 操作”选项卡开始。

Once there, we'll immediately see some starter workflows that Github provides for us to dive in with. Since we're using a node project, we can go ahead and click Set up this workflow under the Node.js workflow.

到达那里后，我们将立即看到Github为我们提供的一些入门工作流程。 由于我们正在使用节点项目，因此我们可以继续并在Node.js工作流下单击“ 设置此工作流”。

After the page loads, Github will land you on a new file editor that already has a bunch of configuration options added.

页面加载后，Github将使您进入一个新的文件编辑器，该文件编辑器已经添加了许多配置选项。

We're actually going to leave this "as is" for our first step. Optionally, you can change the name of the file to tests.yml or something you'll remember.

实际上，我们将第一步保持“原样”。 (可选)您可以将文件名更改为tests.yml或您会记住的名称。

You can go ahead and click Start commit then either commit it directory to the master branch or add the change to a new branch. For this walkthrough, I'll be committing straight to master.

您可以继续并单击“ 开始提交”，然后将其提交到master分支或将更改添加到新分支。 对于本演练，我将直接致力于master 。

To see our new action run, we can again click on the Actions tab which will navigate us back to our new Actions dashboard.

要查看新操作的执行情况，我们可以再次单击“ 操作”选项卡，它将导航我们回到新的“操作”仪表盘。

From there, you can click on Node.js CI and select the commit that you just made above and you'll land on our new action dashboard. You can then click one of the node versions in the sidebar via build (#.x), click the Run npm test dropdown, and we'll be able to see the output of our tests being run (which if you're following along with me, should pass!).

从那里，您可以单击Node.js CI并选择您刚刚在上方进行的提交，您将进入我们新的操作仪表板。 然后，您可以通过build(＃.x)单击侧栏中的节点版本之一，单击“ 运行npm测试”下拉菜单，我们将能够看到正在运行的测试的输出(如果您遵循以下内容，和我在一起，应该通过！)。

Follow along with the commit!

跟随提交！

步骤2：设定新动作 (Step 2: Configuring our new action)

So what did we just do above? We'll walk through the configuration file and what we can customize.

那么，我们刚才在做什么？ 我们将逐步介绍配置文件以及我们可以自定义的内容。

Starting from the top, we specify our name:

从顶部开始，我们指定我们的名称：

name: Node.js CI

This can really be whatever you want. Whatever you pick should help you remember what it is. I'm going to customize this to "Tests" so I know exactly what's going on.

这真的可以是您想要的任何东西。 无论您选择什么，都可以帮助您记住它是什么。 我将自定义为“测试”，所以我确切地知道发生了什么。

on:push:branches: [ master ]pull_request:branches: [ master ]

The on key is how we specify what events trigger our action. This can be a variety of things like based on time with cron. But here, we're saying that we want this action to run any time someone pushes commits to  master or someone creates a pull request targeting the master branch. We're not going to make a change here.

on关键是我们如何指定哪些事件触发我们的动作。 这可能是多种多样的事情，例如基于cron的时间。 但是在这里，我们是说我们希望在有人将提交推送到master或有人创建针对master分支的拉取请求时执行此操作。 我们不会在这里进行更改。

jobs:build:runs-on: ubuntu-latest

This next bit creates a new job called build. Here we're saying that we want to use the latest version of Ubuntu to run our tests on. Ubuntu is common, so you'll only want to customize this if you want to run it on a specific environment.

接下来的一点创建了一个名为build的新作业。 在这里，我们要使用最新版本的Ubuntu来运行测试。 Ubuntu是常见的，因此只有在特定环境下运行时才需要自定义它。

strategy:matrix:node-version: [10.x, 12.x, 14.x]

Inside of our job we specify a strategy matrix. This allows us to run the same tests on a few different variations.

在我们的工作中，我们指定一个战略矩阵。 这使我们可以在几个不同的版本上运行相同的测试。

In this instance, we're running the tests on 3 different versions of node to make sure it works on all of them. This is definitely helpful to make sure your code is flexible and future proof, but if you're building and running your code on a specific node version, you're safe to change this to only that version.

在这种情况下，我们将在3个不同版本的节点上运行测试，以确保其在所有版本上均适用。 这对于确保代码具有灵活性和面向未来的特性绝对有帮助，但是，如果要在特定节点版本上构建和运行代码，则可以安全地将其更改为该版本。

steps:- uses: actions/checkout@v2- name: Use Node.js ${{ matrix.node-version }}uses: actions/setup-node@v1with:node-version: ${{ matrix.node-version }}- run: npm ci- run: npm run build --if-present- run: npm test

Finally, we specify the steps we want our job to run. Breaking this down:

最后，我们指定希望作业运行的步骤。 分解如下：

• uses: actions/checkout@v2: In order for us to run our code, we need to have it available. This checks out our code on our job environment so we can use it to run tests.

  uses: actions/checkout@v2 ：为了使我们运行代码，我们需要使其可用。 这会在工作环境中签出我们的代码，以便我们可以使用它来运行测试。

• uses: actions/setup-node@v1: Since we're using node with our project, we'll need it set up on our environment. We're using this action to do that setup  for us for each version we've specified in the matrix we configured above.

  uses: actions/setup-node@v1 ：由于我们在项目中使用节点，因此需要在环境中对其进行设置。 我们正在使用此操作为我们在上面配置的矩阵中指定的每个版本进行设置。

• run: npm ci: If you're not familiar with npm ci, it's similar to running npm install but uses the package-lock.json file without performing any patch upgrades. So essentially, this installs our dependencies.

  run: npm ci ：如果您不熟悉npm ci ，则类似于运行npm install但是使用package-lock.json文件而不执行任何补丁程序升级。 因此，从本质上讲，这将安装我们的依赖项。

• run: npm run build --if-present: npm run build runs the build script in our project. The --if-present flag performs what it sounds like and only runs this command if the build script is present. It doesn't hurt anything to leave this in as it won't run without the script, but feel free to remove this as we're not building the project here.

  run: npm run build --if-present ： npm run build在我们的项目中运行构建脚本。 --if-present标志执行听起来像的操作，并且仅在存在构建脚本的情况下才运行此命令。 将其保留在其中不会造成任何伤害，因为它不会在没有脚本的情况下运行，但是可以随意删除它，因为我们不在此处构建项目。

• run: npm test: Finally, we run npm test to run our tests. This uses the test npm script set up in our package.json file.

  run: npm test ：最后，我们运行npm test来运行我们的测试。 这使用在package.json文件中设置的test npm脚本。

And with that, we've made a few tweaks, but our tests should run after we've committed those changes and pass like before!

至此，我们进行了一些调整，但是我们应该在完成这些更改并像以前一样通过测试之后运行测试！

Follow along with the commit!

跟随提交！

步骤3：测试我们的测试失败并阻止合并 (Step 3: Testing that our tests fail and prevent merges)

Now that our tests are set up to automatically run, let's try to break it to see it work.

现在我们的测试已设置为自动运行，让我们尝试将其破坏以使其正常运行。

At this point, you can really do whatever you want to intentionally break the tests, but here's what I did:

在这一点上，您真的可以做任何有意破坏测试的事情 ，但这就是我所做的 ：

I'm intentionally returning different expected output so that my tests will fail. And they do!

我有意返回不同的预期输出，因此我的测试将失败。 他们做到了！

In my new pull request, my new branch breaks the tests, so it tells me my checks have failed. If you noticed though, it's still green to merge, so how can we prevent merges?

在我的新请求请求中，我的新分支破坏了测试，因此它告诉我我的检查失败。 如果您注意到了，它仍然是绿色合并，那么我们如何防止合并？

We can prevent pull requests from being merged by setting up a Protected Branch in our project settings.

我们可以通过在项目设置中设置保护分支来防止合并请求。

First, navigate to Settings, then Branches, and click Add rule.

首先，导航至设置 ，然后导航至分支 ，然后点击添加规则 。

We'll then want to set the branch name pattern to *, which means all branches, check the Require status checks to pass before merging option, then select all of our different status checks that we'd like to require to pass before merging.

然后，我们要将分支名称模式设置为* ，这意味着所有分支，选中“ 需要状态检查以在合并之前通过”选项 ，然后选择我们需要在合并之前通过的所有不同状态检查。

Finally, hit Create at the bottom of the page.

最后，点击页面底部的创建 。

And once you navigate back to the pull request, you'll notice that the messaging is a bit different and states that we need our statuses to pass before we can merge.

并且，当您导航回拉请求时，您会注意到消息传递有些不同，并且声明我们需要状态才能通过合并。

Note: as an administrator of a repository, you'll still be able to merge, so this technically only prevents non-administrators from merging. But will give you increased messaging if the tests fail.

注意：作为存储库的管理员，您仍然可以合并，因此从技术上讲，这只能防止非管理员合并。 但是，如果测试失败，将为您增加消息传递。

And with that, we have a new Github Action that runs our tests and prevents pull requests from merging if they fail.

有了这个，我们有了一个新的Github Action，它可以运行我们的测试，并防止合并请求失败时合并请求。

Follow along with the pull request!

跟随拉动要求！

Note: we won't be merging that pull request before continuing to Part 2.

注意：在继续进行第2部分之前，我们不会合并该pull请求。

第2部分：将新的请求请求发布到Slack (Part 2: Post new pull requests to Slack)

Now that we're preventing merge requests if they're failing, we want to post a message to our Slack workspace whenever a new pull request is opened up. This will help us keep tabs on our repos right in Slack.

既然我们可以防止合并请求失败，那么每当新的拉取请求打开时，我们都希望将消息发布到Slack工作区。 这将有助于我们在Slack中保持对存储库的监视。

For this part of the guide, you'll need a Slack workspace that you have permissions to create a new developer app with and the ability to create a new channel for the bot user that will be associated with that app.

在本指南的这一部分中，您将需要一个Slack工作区，该工作区具有创建新的开发人员应用程序的权限，并具有为将与该应用程序关联的机器人用户创建新通道的能力。

步骤1：设定Slack (Step 1: Setting up Slack)

There are a few things we're going to walk through as we set up Slack for our workflow:

在为工作流程设置Slack时，我们需要完成以下几件事：

• Create a new app for our workspace为我们的工作区创建一个新的应用程序
• Assign our bot permissions分配我们的漫游器权限
• Install our bot to our workspace将我们的机器人安装到我们的工作区
• Invite our new bot to our channel邀请我们的新漫游器进入我们的频道

To get started, we'll create a new app. Head over to the Slack API Apps dashboard. If you already haven't, log in to your Slack account with the Workspace you'd like to set this up with.

首先，我们将创建一个新应用。 转到Slack API Apps仪表板 。 如果尚未注册，请使用您要设置的Workspace登录到Slack帐户。

Now, click Create New App where you'll be prompted to put in a name and select a workspace you want this app to be created for. I'm going to call my app "Gitbot" as the name, but you can choose whatever makes sense for you. Then click Create App.

现在，单击“ 创建新应用程序” ，系统将提示您输入名称并选择要为其创建此应用程序的工作区。 我将我的应用称为“ Gitbot”，但是您可以选择任何对您有意义的东西。 然后点击“ 创建应用” 。

Once created, navigate to the App Home link in the left sidebar. In order to use our bot, we need to assign it OAuth scopes so it has permissions to work in our channel, so select Review Scopes to Add on that page.

创建完成后，导航至左侧栏中的App Home链接。 为了使用我们的漫游器，我们需要为其分配OAuth范围，使其具有在我们的渠道中可以使用的权限，因此请在该页面上选择“ 查看要添加的范围” 。

Scroll own and you'll see a Scopes section and under that a Bot Token section. Here, click Add an OAuth Scope. For our bot, we don't need a ton of permissions, so add the channels:join and chat:write scopes and we should be good to go.

滚动“自己”，您将看到“ 作用域”部分以及该“ 机器人令牌”部分下的内容。 在此处，点击添加OAuth范围 。 对于我们的机器人，我们不需要大量权限，因此添加channels:join和chat:write范围，我们应该会做得很好。

Now that we have our scopes, let's add our bot to our workspace. Scroll up on that same page to the top and you'll see a button that says Install App to Workspace.

现在我们有了作用域，让我们将机器人添加到工作区中。 在同一页面上向上滚动到顶部，您会看到一个按钮，指示将应用程序安装到工作区 。

Once you click this, you'll be redirected to an authorization page. Here, you can see the scopes we selected for our bot. Next, click Allow.

单击此按钮后，您将被重定向到授权页面。 在这里，您可以看到我们为机器人选择的范围。 接下来，点击允许 。

At this point, our Slack bot is ready to go. At the top of the OAuth & Permissions page, you'll see a Bot User OAuth Access Token. This is what we'll use when setting up our workflow, so either copy and save this token or remember this location so you know how to find it later.

至此，我们的Slack机器人已准备就绪。 在OAuth＆Permissions页面的顶部，您会看到Bot用户OAuth访问令牌 。 这是我们在设置工作流程时将使用的方式，因此请复制并保存该令牌或记住该位置，以便您以后知道如何查找它。

Note: this token is private - don't give this out, show it in a screencast, or let anyone see it!

注意：此令牌是私有令牌-请勿泄露，在截屏视频中显示或让任何人看到！

Finally, we need to invite our Slack bot to our channel. If you open up your workspace, you can either use an existing channel or create a new channel for these notifications, but you'll want to enter the command /invite @[botname] which will invite our bot to our channel.

最后，我们需要邀请我们的Slack机器人进入我们的频道。 如果打开工作区，则可以使用现有通道或为这些通知创建新通道，但是您需要输入命令/invite @[botname] ，它将邀请我们的机器人进入我们的通道。

And once added, we're done with setting up Slack!

添加完成后，我们就完成了Slack的设置！

创建一个Github动作来通知Slack (Create a Github Action to notify Slack)

Our next step will be somewhat similar to when we created our first Github Action. We'll create a workflow file which we'll configure to send our notifications.

我们的下一步与创建第一个Github Action时有些相似。 我们将创建一个工作流文件，将其配置为发送通知。

While we can use our code editors to do this by creating a file in the .github directory, I'm going to use the Github UI.

尽管我们可以使用代码编辑器通过在.github目录中创建文件来完成此.github ，但我将使用Github UI。

First, let's navigate back to our Actions tab in our repository. Once there, select New workflow.

首先，让我们回到存储库中的“ 操作”选项卡。 在那里，选择新建工作流程 。

This time, we're going to start the workflow manually instead of using a pre-made Action. Select set up a workflow yourself at the top.

这次，我们将手动启动工作流程，而不是使用预制的Action。 选择顶部自己设置工作流程 。

Once the new page loads, you'll be dropped in to a new template where we can start working. Here's what our new workflow will look like:

加载新页面后，您将进入一个新模板，我们可以在其中开始工作。 我们的新工作流程如下所示：

name: Slack Notificationson:pull_request:branches: [ master ]jobs:notifySlack:runs-on: ubuntu-lateststeps:- name: Notify slackenv:SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}uses: abinoda/slack-action@masterwith:args: '{\"channel\":\"[Channel ID]\",\"blocks\":[{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Pull Request:* ${{ github.event.pull_request.title }}\"}},{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"*Who?:* ${{ github.event.pull_request.user.login }}\n*Request State:* ${{ github.event.pull_request.state }}\"}},{\"type\":\"section\",\"text\":{\"type\":\"mrkdwn\",\"text\":\"<${{ github.event.pull_request.html_url }}|View Pull Request>\"}}]}'

So what's happening in the above?

那么上面发生了什么？

• name: we're setting a friendly name for our workflow

  name ：我们为工作流程设置一个友好的名称

• on: we want our workflow to trigger when there's a pull request is created that targets our master branch

  on ：我们希望工作流在创建针对我们的master分支的拉取请求时触发

• jobs: we're creating a new job called notifySlack

  jobs ：我们正在创建一个名为notifySlack的新工作

• jobs.notifySlack.runs-on: we want our job to run on a basic setup of the latest Unbuntu

  jobs.notifySlack.runs-on ：我们希望我们的工作在最新的Unbuntu的基本设置上运行

• jobs.notifySlack.steps: we really only have one step here - we're using a pre-existing Github Action called Slack Action and we're configuring it to publish a notification to our Slack

  jobs.notifySlack.steps ：我们实际上只有一个步骤-我们使用的是预先存在的名为Slack Action的 Github Action ，我们正在配置它以将通知发布到我们的Slack

There are two points here we'll need to pay attention to, the env.SLACK_BOT_TOKEN and the with.args.

这里需要注意两点， env.SLACK_BOT_TOKEN和with.args 。

In order for Github to communicate with Slack, we'll need a token. This is what we're setting in env.SLACK_BOT_TOKEN. We generated this token in the first step. Now that we'll be using this in our workflow configuration, we'll need to add it as a Git Secret in our project.

为了让Github与Slack进行通信，我们需要一个令牌。 这是我们在env.SLACK_BOT_TOKEN设置的。 我们在第一步中生成了此令牌。 现在我们将在工作流配置中使用它，我们需要将其作为Git Secret添加到我们的项目中 。

The  with.args property is what we use to configure the payload to the Slack API that includes the channel ID (channel) and our actual message (blocks).

with.args属性是我们用来配置Slack API的有效负载的工具，其中包括通道ID( channel )和实际消息( blocks )。

The payload in the arguments is stringified and escaped. For example, when expanded it looks like this:

参数中的有效负载被字符串化并转义。 例如，展开时看起来像这样：

{"channel": "[Channel ID]","blocks": [{"type": "section","text": {"type": "mrkdwn","text": "*Pull Request:* ${{ github.event.pull_request.title }}"}}, {"type": "section","text": {"type": "mrkdwn","text": "*Who?:*n${{ github.event.pull_request.user.login }}n*State:*n${{ github.event.pull_request.state }}"}}, {"type": "section","text": {"type": "mrkdwn","text": "<${{ github.event.pull_request._links.html.href }}|View Pull Request>"}}]
}

Note: this is just to show what the content looks like, we need to use the original file with the stringified and escaped argument.

注意：这只是为了显示内容的样子，我们需要使用带有stringified和转义参数的原始文件。

Back to our configuration file, the first thing we set is our channel ID. To find our channel ID, you'll need to use the Slack web interface. Once you open Slack in your browser, you want to find your channel ID in the URL:

回到我们的配置文件，我们设置的第一件事是我们的频道ID。 要找到我们的频道ID，您需要使用Slack网络界面。 在浏览器中打开Slack后，您想在URL中找到您的频道ID：

https://app.slack.com/client/[workspace ID]/[channel ID]

With that channel ID, you can modify our workflow configuration and replace [Channel ID] with that ID:

使用该通道ID，您可以修改我们的工作流程配置，并用该ID替换[Channel ID] ：

with:args: '{\"channel\":\"C014RMKG6H2\",...

The rest of the arguments property is how we set up our message. It includes variables from the Github event that we use to customize our message.

参数属性的其余部分是我们如何设置消息。 它包含来自Github事件的变量，我们使用这些变量来自定义消息。

We won't go into tweaking that here, as what we already have will send a basic pull request message, but you can test out and build your own payload with Slack's Block Kit Builder.

我们不会在这里进行调整，因为我们已经拥有的将发送基本的请求请求消息，但是您可以使用Slack的Block Kit Builder进行测试并构建自己的有效负载。

Follow along with the commit!

跟随提交！

测试我们的Slack工作流程 (Test out our Slack workflow)

So now we have our workflow configured with our Slack app, finally we're ready to use our bot!

现在，我们已经使用Slack应用程序配置了工作流程，终于可以使用我们的机器人了！

For this part, all we need to do is create a new pull request with any change we want. To test this out, I simply created a new branch where I added a sentence to the README.md file.

对于这一部分，我们要做的就是创建一个新的请求，该请求具有我们想要的任何更改。 为了测试这一点，我只是创建了一个新分支 ，在其中向README.md文件添加了一个句子。

Once you create that pull request, similar to our tests workflow, Github will run our Slack workflow! You can see this running in the Actions tab just like before.

与我们的测试工作流程类似， 创建该拉取请求后 ，Github将运行我们的Slack工作流程！ 您可以像以前一样在“操作”选项卡中看到此运行。

As long as you set everything up correctly, once the workflow runs, you should now have a new message in Slack from your new bot.

只要您正确设置了所有内容，工作流程一旦运行，您现在应该会从新的bot在Slack中收到一条新消息。

Note: we won't be merging that pull request in.

注意：我们不会合并该拉取请求。

我们还能做什么？ (What else can we do?)

自定义您的Slack通知 (Customize your Slack notifications)

The message I put together is simple. It tells us who created the pull request and gives us a link to it.

我整理的信息很简单。 它告诉我们谁创建了拉取请求，并为我们提供了链接。

To customize the formatting and messaging, you can use the Github Block Kit Builder to create your own.

要自定义格式和消息，可以使用Github Block Kit Builder创建自己的格式。

If you'd like to include additional details like the variables I used for the pull request, you can make use of Github's available contexts. This lets you pull information about the environment and the job to customize your message.

如果您想包括其他细节，例如我用于请求请求的变量，则可以使用Github的可用上下文 。 这使您可以获取有关环境和作业的信息以自定义消息。

I couldn't seem to find any sample payloads, so here's an example of a sample github context payload you would expect in the event.

我似乎找不到任何示例有效负载，因此这是您在事件中期望的示例github上下文有效负载的示例。

Sample github context

示例github上下文

更多Github动作 (More Github actions)

With our ability to create new custom workflows, that's not a lot we can't automate. Github even has a marketplace where you can browse around for one.

凭借我们创建新的自定义工作流程的能力，我们无法实现很多自动化。 Github甚至有一个市场 ，您可以在那里浏览。

If you're feeling like taking it a step further, you can even create your own! This lets you set up scripts to configure a workflow to perform whatever tasks you need for your project.

如果您想更进一步，甚至可以自己创建！ 这使您可以设置脚本来配置工作流以执行项目所需的任何任务。

加入对话！ (Join in the conversation!)

您将Github动作用于什么？ (What do you use Github actions for?)

Share with me on Twitter!

在Twitter上与我分享！