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

推荐订阅源

Y
Y Combinator Blog
博客园 - 司徒正美
TaoSecurity Blog
TaoSecurity Blog
Martin Fowler
Martin Fowler
T
Threat Research - Cisco Blogs
Blog — PlanetScale
Blog — PlanetScale
S
Secure Thoughts
博客园 - 三生石上(FineUI控件)
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
K
Kaspersky official blog
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Cisco Talos Blog
Cisco Talos Blog
H
Help Net Security
博客园 - 叶小钗
爱范儿
爱范儿
GbyAI
GbyAI
I
Intezer
M
MIT News - Artificial intelligence
Latest news
Latest news
Schneier on Security
Schneier on Security
T
Tor Project blog
Simon Willison's Weblog
Simon Willison's Weblog
I
InfoQ
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
C
CXSECURITY Database RSS Feed - CXSecurity.com
罗磊的独立博客
N
News and Events Feed by Topic
T
The Blog of Author Tim Ferriss
V2EX - 技术
V2EX - 技术
B
Blog
T
Tailwind CSS Blog
N
Netflix TechBlog - Medium
Security Latest
Security Latest
V
V2EX
F
Fortinet All Blogs
Forbes - Security
Forbes - Security
Application and Cybersecurity Blog
Application and Cybersecurity Blog
The Hacker News
The Hacker News
Scott Helme
Scott Helme
P
Privacy International News Feed
P
Palo Alto Networks Blog
H
Heimdal Security Blog
C
Cisco Blogs
T
The Exploit Database - CXSecurity.com
博客园 - Franky
酷 壳 – CoolShell
酷 壳 – CoolShell
G
Google Developers Blog
W
WeLiveSecurity
L
LINUX DO - 最新话题

Zhullyb's Blog

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 监控 Fedora Copr 构建状态 | 竹林里有冰的博客
竹林里有冰 · 2025-02-23 · via Zhullyb's Blog

确信,是 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 的触发频率好了。