• author

第71节 Prow及其生态系统

⬆️上一节🔗 ⬇️下一节🔗

❤️💕💕新时代拥抱云原生，云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.top

---

[TOC]

why?

故事是从这个 proposal 开始idea~

🤖 OpenIM cicd robot machine proposal

Prow是基于Kubernetes的CI/CD系统。作业可以由各种类型的事件触发，并将其状态报告给许多不同的服务。除了作业执行，Prow还以策略执行、通过 /foo 风格命令的聊天操作和自动PR合并的形式提供GitHub自动化。

有关 Golang 文档，请参阅 GoDoc。请注意，这些库仅供prow使用，我们不会尝试保留向后兼容性。

Kubernetes 专门为 Prow 提供了网页命令查询：

• https://prow.k8s.io/command-help

关于Prow如何运行作业的简要概述，请参阅 Prow作业的生命周期。

要查看Prow的常用用法和交互流，请参见拉取请求交互序列图。

hello world

最简单的一个上手案例莫过于 pull request 。

提出一个拉取请求（以下简称PR）。在PR正文中，可以随意添加区域标签（如果合适），例如 /area <AREA> 。标签列表在这里。也可以随意推荐一位评论者 /assign @theirname 。

一旦您的审阅者满意，他们会说 /lgtm ，这将应用 lgtm 标签，如果他们是OWNER，将应用 approved 标签。 approved 标签也将自动应用于所有者打开的PR。如果您和您的审阅者都不是OWNER，请 /assign 某个所有者。如果您的PR有 lgtm 和 approved 标签，没有任何 do-not-merge/* 标签，并且所有测试均通过，则PR将自动合并。

查看测试结果

• Kubernetes TestGrid 显示历史测试结果
  • 在 testgrid/config.yaml 配置自己的 testgrid 仪表盘
  • Gubernator 格式化每次运行的输出
• PR Dashboard 查找需要注意的 PR
• Prow 安排测试并更新问题
  • Prow 响应 GitHub 事件、定时器和在 GitHub 评论中给出的手动命令。
  • prow dashboard 显示当前正在测试什么
  • 在 config/jobs 配置 prow 运行新测试
• Triage Dashboard 汇总故障
  • 将故障集群在一起
  • 搜索跨作业的测试失败
  • 在特定的测试和/或作业的 regex 中过滤失败
• Velodrome 指标跟踪作业和测试健康状况。
  • Kettle 进行收集，metrics 进行报告，velodrome 是前端。

功能和特性

prow 的功能很强大，甚至是比 actions 更加出众。可以测试、批处理、工件发布的作业执行。

• GitHub事件用于触发post-PR-merge（postsubmit）作业和on-PR-update（presubmit）作业。
• 支持多个执行平台和源代码审查站点。

可插拔的GitHub bot自动化，实现 /foo 风格的命令并强制执行配置的策略/流程。

什么是 foo 风格

/foo 风格通常指的是在聊天应用程序（如Slack）中使用的命令格式。这种格式的命令以斜杠 / 开头，后跟一个关键字或短语，例如 /help 或 /status。GitHub bot自动化可以使用此格式来实现特定功能，例如在GitHub上自动创建问题或拉取请求，并强制执行特定的工作流程或策略。

其他的功能：

• GitHub将自动化与批量测试逻辑合并。
• 用于查看作业、合并队列状态、动态生成的帮助信息等的前端。
• 基于配置的源代码管理的自动部署。
• 在源代码控制中配置的自动 GitHub org/repo 管理。
• 专为具有数十个存储库的多组织规模而设计。(The Kubernetes Prow实例仅使用1个GitHub bot令牌！）
• 高可用性是在Kubernetes上运行的好处。（复制、负载平衡、滚动更新...）
• JSON结构化日志。
• 支持 普罗米修斯指标。

Documentation

任何一个大型的工程第一个考虑的应该是稳定性，prow的稳定性很大程度上依赖于单元测试和集成测试。

• 单元测试与prow源代码位于同一位置
• Integration tests utilizes kind with hermetic integration tests. See instructions for adding new integration tests for more details

Getting started：我们分为三个大的板块

• 使用自己的 Prow 部署
• 为 Prow 开发
• As a job author: ProwJobs

使用自己的Prow部署

这里我们应该学会的是如何将你自己的 Prow 实例部署到 Kubernetes 的集群。

Prow可以在任何Kubernetes集群中运行。下面的指南专注于Google Kubernetes Engine，但应该适用于任何Kubernetes发行版，无需/只需 很少的更改。

Prow 是使用 webhook 做的，webhook 相对来说比较复杂一些。

就是当你创建 robot 的时候，先创建 webhook，然后写入 webhook 链接。

k8s有自己的服务，prew 需要单独搭建出来。

webhook的地址是你写的服务的公网地址。相当于github要调用webhook

其实你写个webhook然后把webhook搭建到cloud上，就串起来了。然后你自动发布就直接改镜像完事。主要就是把webhook写一下，解析指令就行了。

如果你没有自己的服务器，也可以借助 actions 自己跑，参考：https://github.com/labring/sealos/blob/main/.github/workflows/bot.yml

GitHub APP

首先，您需要 创建一个GitHub应用程序。GitHub本身也记录了这一点。 最初，为Webhook设置一个虚拟URL就足够了。所需的确切权限集因您使用的功能而异。下面是所需的最低权限集。

⚠️ 一个用户或者组织最多只能有 100 个 robot

存储库权限：

• Actions：只读（仅在使用合并自动化 tide 时需要）
• Administration：只读（获取团队和协作者时必需）
• Checks：只读（仅在使用合并自动化 tide 时需要）
• Contents：读取（使用合并自动化时需要读取和写入 tide ）
• Issues: Read & write
• Metadata: Read-Only
• Pull Requests: Read & write
• projects：使用 projects 插件时为Admin，否则为none
• Commit statuses: Read & write

组织权限：

• Members：只读（使用 peribolos 时读写）
• projects：使用 projects 插件时为Admin，否则为none

在 Subscribe to events 中选择所有事件。

保存应用程序后，单击底部的“生成私钥”，并将私钥与页面顶部的 App ID 一起保存。

sealos 也集成了自己的 robot，可以作为发行版或者是解决平常的 PR

• sealos-release-rebot
• k8s-release-robot

关于 sealos 的 bot 仓库地址，藏在了这里

如何做一个 github-bot

GitHub机器人是一种自动化工具，它可以在服务端上启动一个基于 Koa.js 的HTTP服务器，并建立一些项目规范，例如规定issue格式、pull request格式、配置指定标签的所有者、统一git commit log格式等。通过使用 GitHub Webhooks 和 GitHub API，机器人可以自动处理一些事情，例如自动回复issue、自动合并pull request等。通常情况下，机器人是一个单独的账号，例如 @kubbot。使用GitHub机器人可以实现快速响应、自动化和解放人力的效果，从而提高项目的效率和质量。

actions 关闭和操作 issue

其实 robot 最基本的权限就是对 issue 和 PR 的权限。

name: Invite users to join our group
on:
  issue_comment:
    types:
      - created
jobs:
  issue_comment:
    name: Invite users to join our group
    if: ${{ github.event.comment.body == '/invite' }}
    runs-on: ubuntu-latest
    permissions:
      issues: write
    steps:

      - name: Invite user to join our group
        uses: peter-evans/create-or-update-comment@v1
        with:
          issue-number: ${{ github.event.issue.number }}
          body: |
			#......

      - name: Close Issue
        uses: peter-evans/close-issue@v3
        with:
          issue-number: ${{ github.event.issue.number }}
          comment: auto-closing issue, if you still need help please reopen the issue or ask for help in the community above
          labels: |
            triage/accepted

github 地址：

• https://github.com/peter-evans/close-issue

最后还贴心的加上 labels

再来一个：Issues Translate Chinese Action

将包含中文 issue 实时翻译成英文 issue 的 action。

name: 'issue translator'
on:
  issue_comment:
    types: [created]
  issues:
    types: [opened]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: usthe/issues-translate-action@v2.7
        with:
          # it is not necessary to decide whether you need to modify the issue header content
          IS_MODIFY_TITLE: true
          BOT_GITHUB_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
          # Required, input your bot github token这里有一点很神奇，就是我们不需要去指定 GitHub 中 BOT 的用户 @kubbot ，GitHub在环境密钥中就可以知道、解析出来。

用了上面的模板后，GitHub就能自动的去分析 issue 并且翻译。

还有一个是用的 chatgpt 翻译的：

• https://github.com/marketplace/actions/gpt-translate

在问题或拉取请求中创建带有 /gpt-translate 或 /gt 的评论。

[On issue]转换后的文件将作为拉取请求创建。

[On pull request]转换后的文件将通过新提交添加到pull request中。

换句话说，如果你继续评论一个问题，新的PR将不断被创建。如果你一直在PR上评论，新的提交将不断地被添加到该PR中。

/gpt-translate README.md README_zh-CN.md traditional-chinese

actions 文件：

@kubbot

# .github/workflows/gpt-translate.yml
name: GPT Translate

on:
  issue_comment:
    types: [ created ]

jobs:
  gpt_translate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Run GPT Translate
        if: |
          contains(github.event.comment.body, '/gpt-translate') || 
          contains(github.event.comment.body, '/gt')
        uses: 3ru/gpt-translate@v1.0
        with:
          apikey: ${{ secrets.OPENAI_API_KEY }}
          token: "${{ secrets.BOT_GITHUB_TOKEN }}"

如何使用指定的GitHub robot 代替 GitHub actions

每一次看到 GitHub actions，感觉看着不顺眼，还不如搞一个自己的 robot。

Lighthouse

Lighthouse是一个轻量级的基于 ChatOps 的 webhook 处理程序，可以基于来自多个git提供商（如GitHub，GitHub Enterprise，BitBucket Server和GitLab）的webhook触发Jenkins X Pipelines，Tekton Pipelines或Jenkins Jobs。

Lighthouse 最开始的时候也是基于 prow 的，并且是从他们的基础代码的副本开始。

目前，Lighthouse支持标准的Prow插件，并处理将webhook推送到分支，然后在您选择的代理上触发管道执行。

Lighthouse使用与Prow相同的 config.yaml 和 plugins.yaml 进行配置。

基础满足

创建 access tokens

https://github.com/settings/tokens （需要在 .env 里配置）

创建 webhook

https://github.com/用户名/项目名/settings/hooks/new

• Payload URL: www.example.com:8000
• Content type: application/json
• trigger: Send me everything.
• Secret: xxx （需要在 .env 里配置）

开发运行

npm install
cp env .env
vim .env
npm start

部署

本项目使用 pm2 进行服务管理，发布前请先全局安装 pm2

npm install pm2 -g
npm run deploy

后台启动该服务后，可以通过 pm2 ls 来查看服务名称为 github-bot 的运行状态。具体 pm2 使用，请访问：https://github.com/Unitech/pm2

日志系统说明

本系统 logger 服务基于 log4js。 在根目录的 .env 文件中有个参数 LOG_TYPE 默认为 console，参数值说明：

console - 通过 console 输出log。
file - 将所有相关log输出到更根目录的 `log` 文件夹中。

END 链接

Link

• prow docs
• github kubernetes/test-infra/prow/cron
• using commond
• @k8s-ci-robot
• @ks-ci-bot

参考文章

• xuexb GitHub
• sealos gh rebot
• https://www.amoyw.com/2020/10/22/Prow/

导航

• ⬆️上一节🔗 ️下一节🔗

• Ⓜ️回到目录🏠

• 🫵参与贡献💞❤️‍🔥💖)

• ✴️版权声明 © ：本书所有内容遵循CC-BY-SA 3.0协议（署名-相同方式共享）©