惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

云风的 BLOG
云风的 BLOG
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
IT之家
IT之家
Recent Announcements
Recent Announcements
B
Blog
D
Docker
V
V2EX
GbyAI
GbyAI
L
LangChain Blog
博客园 - Franky
U
Unit 42
T
The Blog of Author Tim Ferriss
A
About on SuperTechFans
博客园 - 【当耐特】
Google DeepMind News
Google DeepMind News
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Vercel News
Vercel News
博客园_首页
D
DataBreaches.Net
人人都是产品经理
人人都是产品经理
Y
Y Combinator Blog
量子位
Blog — PlanetScale
Blog — PlanetScale
罗磊的独立博客

竹林里有冰的博客

Nuxt SSG 博客的尾斜杠到底怎么加? | 竹林里有冰的博客 小米 Xiaomi Book Pro 14 (Ultra X7) Linux 兼容性实测 | 竹林里有冰的博客 国内(大陆)版小米 FCM 熄屏断连:Rootless 环境下的尝试与可能的解决方案 | 竹林里有冰的博客 我没法访问 dl.google.com —— 记一次 TUN 下的网络 debug | 竹林里有冰的博客 Vercel 的缓存控制,你注意过吗? | 竹林里有冰的博客 小记 —— Caddy 在 Layer 4 上的流量代理实践 | 竹林里有冰的博客 你的域名后缀拖慢你的网站速度了嘛?——再谈 DNS 冷启动 | 竹林里有冰的博客 DNS 冷启动:小型站点的“西西弗斯之石” | 竹林里有冰的博客 HTTP/2 Server Push 已事实性“死亡”,我很怀念它 | 竹林里有冰的博客 Nuxt Content v3 中数组字段的筛选困境与性能优化 | 竹林里有冰的博客 后 OCSP 时代,浏览器如何应对证书吊销新挑战 | 竹林里有冰的博客 初试 Github Action Self-hosted Runner,想说爱你不容易 | 竹林里有冰的博客 DNS 解析延迟毁了我的图床优化 | 竹林里有冰的博客 Vue Markdown 渲染优化实战(下):告别 DOM 操作,拥抱 AST 与函数式渲染 | 竹林里有冰的博客 Vue Markdown 渲染优化实战(上):从暴力刷新、分块更新到 Morphdom 的华丽变身 | 竹林里有冰的博客 node-sass 迁移至 dart-sass 踩坑实录 | 竹林里有冰的博客 前端中的量子力学——一打开 F12 就消失的 Bug | 竹林里有冰的博客 2025 年,如何为 web 页面上展示的视频选择合适的压缩算法? | 竹林里有冰的博客 el-image 和 el-table 怎么就打架了?Stacking Context 是什么? | 竹林里有冰的博客 2025年,前端如何使用 JS 将文本复制到剪切板? | 竹林里有冰的博客 ssh 拯救世界——通过 ssh 隧道在内网服务器执行 APT 更新 | 竹林里有冰的博客 Cudy TR3000 吃鹅(daed)记 | 竹林里有冰的博客 基于 Cloudflare Workers 实现的在线服务状态检测告警系统 | 竹林里有冰的博客 构建部署在 Cloudflare Workers 上的 TG Bot | 竹林里有冰的博客 2024年,Firefox 是唯一还在坚持执行在线的 SSL 证书吊销状态检查的主流浏览器 | 竹林里有冰的博客 小爱课程表适配不完全指北——以 ZJUT 本科正方教务系统为例 | 竹林里有冰的博客 将博客从 waline v2 更新到 waline v3 | 竹林里有冰的博客 给家里云装上 Fedora 41 KDE 后,我是如何配置的 | 竹林里有冰的博客 为 Hexo 添加 follow 认证 | 竹林里有冰的博客 使用 GPT 对 waline 的评论进行审查 | 竹林里有冰的博客
使用 Cloudflare Workers 监控 Fedora Copr 构建状态 | 竹林...
竹林里有冰 · 2025-02-23 · via 竹林里有冰的博客

确信,是 cloudflare workers 用上瘾了

「使用 Github Action 更新用于 rpm 打包的 spec 文件」一文中,我利用 Github Action 实现了自动化的 spec 版本号更新,配合 Fedora Copr 的 webhook 就可以实现 Copr 软件包更新的自动化构建。看似很完美,但缺少了一个构建状态的监控机制,这导致出现构建错误的时候我不能及时得到通知(无论构建错误是 spec 本身的问题或者是构建时的网络环境问题)。

西木野羰基 提出 notifications.fedoraproject.org 可以配置通知,Filters 的 Applications 选项中有 copr,但很可惜,实测没有效果。这里的通知配置的似乎只是邮件的过滤规则——如果 copr 本来就没打算构建失败的时候给你发邮件,那即使建立了过滤规则,依然是不可能收到邮件的。

不过好在 Fedora Copr 本身有非常完备的 api 文档/monitor 这个 API 能用来获取软件包最新的构建情况。

因此,我们就可以通过 Cloudflare 的 cronjob 定时请求这个接口,查询是否有软件包构建失败。

先来编写打请求的部分

async function fetchCopr() {
    const ownername = "zhullyb";
    const projectname = "v2rayA";

    const url = new URL("https://copr.fedorainfracloud.org/api_3/monitor")
    url.searchParams.set("ownername", ownername)
    url.searchParams.set("projectname", projectname)
    const response = await fetch(url)
    const data = await response.json()
    if (data.output !== "ok") {
        throw new Error("Failed to fetch COPR data")
    }
    return data
}

随后编写通知部分,我这里采用的是飞书的 webhook 机器人

async function notify(text) {
    const webhook = "https://open.feishu.cn/open-apis/bot/v2/hook/ffffffff-ffff-ffff-ffff-ffffffffffff"
    const body = {
        msg_type: "text",
        content: {
            text: text
        }
    }
    const response = await fetch(webhook, {
        method: "POST",
        headers: {
            "Content-Type": "application/json"
        },
        body: JSON.stringify(body)
    })
    console.log(response)
}

最后就是 cronjob 的调用部分和构建状态解析部分

export default {
    async fetch(request, env, ctx) {
      return new Response('Hello World!');
    },

    async scheduled(event, env, ctx) {
        const data = await fetchCopr()
        const errorPackages = new Array()

        for (const pkg of data.packages) {
            for (const chroot of Object.values(pkg.chroots)) {
                if (chroot.state == "failed") {
                    errorPackages.push(pkg.name)
                    break
                }
            }
        }

        if (errorPackages.length > 0) {
            await notify(`COPR 以下包发生构建失败:\n${errorPackages.join("\n")}`)
        } else {
            console.log("COPR 所有包构建成功")
        }
    }
};

随后在 Cloudflare Workers 的 Settings 部分设置好 Cron 表达式即可,我这里选择在每小时的 55 分进行一次检测,这样下来一天只会消耗 24 次 workers 次数,简直毫无压力。

缺点: 我懒得使用持久化数据库记录软件包构建的成功状态,这会导致出现一个包构建失败后,每隔 1 小时都会有一条提醒,什么夺命连环 call。我目前不想修复这个问题,要不然还是降低 cron 的触发频率好了。