标签 GitHub Actions 下的文章

在过去一年中,我们见证了多起重大攻击事件,例如 Shai-Hulud 蠕虫攻击、Nx 构建系统被攻破,以及通过 tj-actions/changed-files 漏洞导致机密信息泄露到公开的 GitHub Actions 日志中。但仅仅是罗列各种攻击事件,就足以占据本文的全部篇幅,更不用说深入探讨了。

作为一个行业和生态系统,我们能感受到攻击频率的日益增加。仅在 2024 年,报告的恶意软件包数量就同比增长了 156%。鉴于 Mend 托管的 Renovate Cloud 平台受信于超过 130 万个代码仓库,我们在保护开源软件消费者方面处于非常有利的地位,同时也为自托管 Renovate 的用户提供了更强的安全默认设置。在一系列备受瞩目的 npm 供应链安全攻击之后,Mend Renovate 的维护者们决定,对于选择采纳“最佳实践”配置的用户,默认启用这项安全功能是最佳选择。

为了帮助客户更好地应对这些日益增多的攻击,维护团队正在 Mend Renovate 现有的“最佳实践”配置之上进行构建。该团队一直致力于提供更多“默认即安全”的配置,并首先从 npm 生态系统着手。

在最新的 Mend Renovate 42 版本中,使用“最佳实践”配置的用户将会发现,npm 生态系统中的依赖项更新现在需要通过一个“最短发布时间”的检查,即某个更新发布后必须经过 3 天的窗口期,Mend Renovate 才会提议进行更新。通过这种方法,组织可以确保只有经过验证的、稳定的和值得信赖的依赖项更新才能进入生产环境,从而在保持开发者效率的同时,最终降低供应链攻击的风险。

这有何帮助?
尽管影响广泛,但这些攻击通常利用了两种常见情况:

  • 依赖项的精确版本未被锁定。
  • 依赖项的精确版本已被锁定,但我们在其发布后极短时间内就尝试更新。

不锁定依赖项版本可能有其合理的原因。例如,在 npm 生态系统中,当你发布一个拥有若干依赖项且被许多其他包所依赖的包时。

如果每次你提升一个依赖版本都需要发布自己的包,那么所有依赖于你的包也同样需要提升版本并发布新版,从而在整个生态系统中引发连锁效应。

其中一些过程可以通过自动化来简化——自然是使用像 Mend Renovate 或 GitHub 的 Dependabot 这样的工具,但这仍然需要一定程度的人工审查。

与此同时,不锁定我们的依赖项可能会导致问题,用户可能会立即开始下载一个包的新版本。
在推荐锁定依赖版本后,下一个问题是我们应该多久更新一次。许多工具中现有的默认设置是“一旦有新版本就立即更新”,这可能导致一个恶意升级在其发布几分钟内就被创建为拉取请求 (Pull Request)。

尽管那个恶意的依赖项可能不会进入您开发人员的机器——但它有可能从您的自动化构建管道中窃取机密或其他特权信息——或者利用您 AI 驱动的代码审查工具中的提示注入漏洞。

如果我们增加软件包发布与它出现在您项目的拉取请求中的时间间隔,这就为安全研究人员和自动化安全工具提供了更多时间来发现软件包中的恶意意图,从而减少供应链攻击的可能性。
Mend Renovate 如何助力保障整个生态系统的安全

如上所述,在 Mend Renovate 的最新版本中,我们为所有使用“最佳实践”配置的用户启用了“最短发布时间”检查的强制执行。这适用于更新任何使用 npm 数据源的包,无论其使用的是何种 JavaScript/TypeScript 包管理器。

这项强制执行将:

  • 确保给定的依赖项更新包含其发布时间的元数据(“发布时间戳”)。
  • 确保在该版本发布后未满最少 3 天之前,不会创建任何分支。

如果发现不满足此要求的包更新,Mend Renovate 的依赖项仪表板中将包含一个“等待状态”的条目,并且需要人工明确请求才能更新——从而确保只有“安全”的包更新才会被提出。

(这里的一个告诫是,增加等待时间并不一定意味着所有问题都能被发现——由于针对性攻击或复杂的规避技术,所有问题可能无法都被捕获。)

通过将此功能直接添加到我们的“最佳实践”配置中,那些已经选择遵循行业最佳实践的用户将默认受到保护。而其他所有人也能够添加此功能,例如:
codeJSON

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["security:minimumReleaseAgeNpm"]
}

此外,还可以调整此行为——将等待窗口设置得任意长或短——或者对受信任的内部开发包绕过“最短发布时间”功能。

纵深防御
除了让 Mend Renovate 在满足特定条件(即经过一个给定的窗口期)前不发起更新之外,我们还建议建立多层防御:

在可能的情况下,在您的包管理器中启用此功能,以保护开发人员的机器;和/或在您的自动化构建管道中启用此功能,在发布窗口期过去之前使构建失败。

在撰写本文时,pnpm 10.6 和 yarn 4.2.0 已添加了对这些功能的支持,我们也看到其他包管理器正在考虑添加类似功能。

下一步计划?
继此版本的工作之后,维护团队将继续研究其他包生态系统,以便为我们的“最佳实践”配置启用相应功能,从而进一步保障面向消费者的产品和内部开发环境的安全!

部署到 Cloudflare Workers

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Cloudflare 凭证

  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • CLOUDFLARE_API_TOKEN:你的 API 令牌
      • CLOUDFLARE_ACCOUNT_ID:你的 Account ID
  4. 触发部署

    • 推送代码到 main 分支会自动触发部署
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Cloudflare Workers 控制台中绑定你的自定义域名

部署到 Cloudflare Pages

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Cloudflare 凭证

  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • CLOUDFLARE_API_TOKEN:你的 API 令牌
      • CLOUDFLARE_ACCOUNT_ID:你的 Account ID
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Pages 兼容格式并同步到 pages 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Cloudflare Pages 控制台中绑定你的自定义域名

注意pages 分支是从 main 分支自动生成的。请勿手动编辑 pages 分支,因为它会被同步工作流覆盖。

部署到 EdgeOne Pages

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 EdgeOne Pages API Token

  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secret:
      • EDGEONE_API_TOKEN:你的 API Token
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Pages 兼容格式并同步到 pages 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 EdgeOne Pages 控制台中绑定你的自定义域名

注意pages 分支是从 main 分支自动生成的。请勿手动编辑 pages 分支,因为它会被同步工作流覆盖。

部署到 Vercel

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Vercel 凭证

    • 访问 Vercel Account Settings 创建并记录 Access Token
    • 访问 Team Settings 记录 Team ID
    • 新建项目后访问项目的 Settings 记录 Project ID
  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • VERCEL_TOKEN:你的 Access Token
      • VERCEL_ORG_ID:你的 Team ID
      • VERCEL_PROJECT_ID:你的 Project ID
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Functions 兼容格式并同步到 functions 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Vercel 控制台中绑定你的自定义域名

注意functions 分支是从 main 分支自动生成的。请勿手动编辑 functions 分支,因为它会被同步工作流覆盖。

部署到 Netlify

  1. fork 本存储库Fork xixu-me/Xget

  2. 获取 Netlify 凭证

    • 访问 Netlify User Settings 创建并记录 personal access token
    • 新建项目后访问 Project configuration 记录 Project ID
  3. 配置 GitHub Secrets

    • 进入你的 GitHub 存储库 → Settings → Secrets and variables → Actions
    • 添加以下 secrets:
      • NETLIFY_AUTH_TOKEN:你的 personal access token
      • NETLIFY_SITE_ID:你的 Project ID
  4. 触发部署

    • 存储库会自动将 Workers 代码转换为 Functions 兼容格式并同步到 functions 分支
    • 推送代码到 main 分支会自动触发同步和部署工作流
    • 仅修改文档文件(.md)、LICENSE.gitignore 等不会触发部署
    • 也可以在 GitHub Actions 页面手动触发部署
  5. 绑定自定义域名(可选):在 Netlify 控制台中绑定你的自定义域名

注意functions 分支是从 main 分支自动生成的。请勿手动编辑 functions 分支,因为它会被同步工作流覆盖。

部署到 Deno Deploy

  1. fork 本存储库Fork xixu-me/Xget

  2. 切换默认分支

    • 进入你的 GitHub 存储库 → Settings → General → Default branch
    • 将默认分支从 main 切换到 functions
  3. 部署到 Deno Deploy

  4. 绑定自定义域名(可选):在 Deno Deploy 控制台中绑定你的自定义域名

注意functions 分支是从 main 分支自动生成的。请勿手动编辑 functions 分支,因为它会被同步工作流覆盖。

自托管部署

如果你希望在自己的服务器上运行 Xget,可以使用 Docker 或 Podman 部署:

使用预构建镜像

从 GitHub Container Registry 拉取并运行预构建的镜像:

使用 Docker:

# 拉取最新镜像
docker pull ghcr.io/xixu-me/xget:latest

# 运行容器
docker run -d \
  --name xget \
  -p 8080:8080 \
  ghcr.io/xixu-me/xget:latest

使用 Podman:

# 拉取最新镜像
podman pull ghcr.io/xixu-me/xget:latest

# 运行容器
podman run -d \
  --name xget \
  -p 8080:8080 \
  ghcr.io/xixu-me/xget:latest

本地构建

从源码构建容器镜像:

使用 Docker:

# 克隆存储库
git clone https://github.com/xixu-me/Xget.git
cd Xget

# 构建镜像
docker build -t xget:local .

# 运行容器
docker run -d \
  --name xget \
  -p 8080:8080 \
  xget:local 

使用 Podman:

# 克隆存储库
git clone https://github.com/xixu-me/Xget.git
cd Xget

# 构建镜像
podman build -t xget:local .

# 运行容器
podman run -d \
  --name xget \
  -p 8080:8080 \
  xget:local 

使用 Docker Compose / Podman Compose

创建 docker-compose.yml 文件:

version: '3.8' services: xget:  ghcr.io/xixu-me/xget:latest container_name: xget ports: - "8080:8080" restart: unless-stopped 

使用 Docker Compose:

docker compose up -d

使用 Podman Compose:

podman compose up -d

部署完成后,Xget 将在 8080 端口运行。

注意:自托管部署不包括全球边缘网络加速,性能取决于你的服务器配置和网络环境。


📌 转载信息
原作者: xixu-me
转载时间: 2026/1/25 23:15:14

“我的笔记本是 16G 内存的 M3 Pro ,为什么我还需要一台只有 4 核 8G 的服务器?”

在 Reddit 的 r/indiehackers 板块,这是新手最常问的问题之一。在 Serverless (如 Vercel )和 PaaS (如 Supabase )横行的今天,VPS ( Virtual Private Server ,虚拟专用服务器)似乎显得有些“老派”。

但现实是:真正能跑通商业闭环、实现长期盈利的独立开发者,手里一定攥着几台 VPS 。

本文将从独立开发的 7 个核心痛点出发,深度解析为什么 VPS 是你迈向专业化、摆脱“代码玩具”的必经之路。


1. 摆脱“本地焦虑”:解决 node_modules 与 Docker 的空间黑洞

独立开发者最昂贵的资产是笔记本,而最廉价的则是笔记本硬盘。这波 AI 编程大部分都是 NextJS ,这也就带来了 node_modules 灾难。其实还有 cc 居然也喜欢拉 bb 。如果观察 cc 的执行过程,会发现它一直要写东西去 /tmp 目录

  • 痛点:硬盘与性能的双重榨干


    • node_modules 爆炸:同时维护 10 个项目,node_modules 能吃掉 50GB 以上的 SSD 。
    • Docker 镜像堆积:在本地运行容器会让系统响应迟滞,风扇咆哮。
    • 计算占用:本地运行 PostgreSQL 或 Redis 等中间件会显著拖慢 IDE 的响应速度。
  • 解决方案:VPS 作为“重型计算中心”
    你只需在本地保留一个轻量的 VS Code + Cursor,通过 Remote SSH 连接 VPS 。所有的重型依赖和环境都在云端运行,笔记本只负责显示 UI 。

图 1:本地开发负载 vs. VPS 远程卸载对比

2. 拒绝“SaaS 账单勒索”:从商业逻辑看成本控制

独立开发最怕的不是没用户,而是用户还没付钱,SaaS 账单先爆了。最近几年做 AI 编程,难免会接触到 supabase ,clerk 等工具,其实包括 vercel 也一样,用下来会发现一开始很爽,然后爽着爽着,账单就爆炸了。vercel 有个很有意思的坑,就是 Image 组件,编译的时候会提示最好用 <Image 组件,听起来很贴心对吧?但这个组件默认走 Vercel 的图片优化服务——每优化一张图就计费一次。流量大的站点,光图片优化费用就能超过主机费用。

Vercel 的 Hobby 免费套餐非常诱人——部署、CDN 、SSL 全包。但一旦你的项目有了流量,噩梦就开始了。

超额收费一览

资源 Pro 套餐包含 超出后收费
带宽 1 TB/月 $0.15/GB(即 $150/TB )
Edge Requests 1000 万/月 $2/百万
Serverless 执行时间 40 小时/月 $5/小时
图片优化 5000 张/月 $5/1000 张
  • 痛点:被绑架的扩展成本


    • PaaS 陷阱:Firebase 的免费额度诱人,但一旦涉及复杂备份或高并发,价格呈指数级增长。
    • 身份验证收费:Clerk 等按月活用户收费,对高频低客单价应用是噩梦。
  • 解决方案:全栈自建( Self-hosting )
    在 $5/月 的 VPS 上,你可以利用 Docker 跑满性能,同时运行:数据库( PostgreSQL )、验证系统( PocketBase )和统计系统( Umami )。

图 2:SaaS 订阅 vs. VPS 固定成本曲线对比

💡 公平地说:自建服务确实需要一定的运维能力。但最近很多海外开发者分享了自己维护 PostgreSQL 的经验——比想象中简单得多,尤其是有了 Docker 和自动备份脚本之后。后面我会详细讲怎么做。

3. 真正的 CI/CD:构建“一人 IT 部门”的自动化流水线

独立开发者的核心竞争力在于迭代速度。部署到 vercel 、cloudflare 、Netfily 等 servless 平台在早期验证需求的时候,是非常好的,但是这些平台的问题是,它们的 node 实现是不完备的,一些长时间的任务就没法跑。以前本地打包机器就开始呼啸,通过 github 的 action ,这个事不用操心了,弄好就是 docker 镜像,然后,起飞了。

  • 执行时间限制:Serverless 函数通常有 10-60 秒的超时限制,一般默认是 10s

  • 无持久进程:WebSocket 、长连接、后台任务都很别扭

  • 冷启动延迟:首次请求可能需要等待数秒

  • 痛点:手动部署的低效与错误
    如果你还在用手动执行 git pull,你不仅在浪费生命,还在增加生产事故的概率。

  • 解决方案:基于 VPS 的轻量自动化
    利用 VPS 运行 GitHub Actions Runner


    1. Git Push 触发流水线。
    2. VPS 自动拉取代码并构建 Docker 镜像。
    3. Docker Compose 自动重启容器,实现零停机更新。

图 3:基于 VPS 的自动化 CI/CD 流水线示意图

不知道是不是这个原因,现在 cloudflare 也不咋推 pages 了,又回到 worker ,感觉挺难用的,你怎么看?

4. 解决“网络壁垒”:从静默爬虫到跨境访问

很多项目在本地跑不通,不是代码问题,而是网络环境问题。开发用都的很多 npm 包,或者其他的资源,常常会因为网络,把人给气死,累死,折腾死,烦死。

  • 痛点:变动的 IP 与受限的出口


    • 固定 IP 需求:对接 Stripe 、PayPal 或银行 API 时,通常需要固定的公网 IP 做白名单。家庭宽带的动态 IP 根本没法用。
    • 网络环境问题:开发时用到的很多 npm 包、Docker 镜像、GitHub 资源,经常因为网络问题把人折腾得够呛。
    • 反爬虫封禁:如果你在做数据采集相关的项目,家庭宽带 IP 极易被反爬策略封禁。
  • 解决方案:VPS 作为全局网络枢纽


    • 固定身份标识:为业务提供永久的公网 IP ,Stripe Webhook 、OAuth 回调都能稳定工作。
    • 反向代理中心:一个 VPS 配合 Nginx 或 Caddy ,可以管理 10+ 个域名并映射到不同的本地端口。
    • 开发环境加速:npm install 、docker pull 都在 VPS 上执行,下载速度飞快,不再受本地网络限制。

image.png

和 nginx proxy manager 有仇,已经好几次了,弄它的 Docker ,能占 10 来 G 的空间,完全不理解,caddy 就小巧很多。

5. 守护“睡后收入”:24/7 监控与容灾

独立开发最痛苦的时刻,是早上醒来发现服务已经挂了一整晚,而你毫无察觉。(希望是伪命题,真来钱的项目,还是很上心的!)

痛点:缺乏哨兵

  • 本地电脑会休眠,没法做持续监控
  • 免费的外部监控工具检测频率太低(如 5 分钟/次),发现问题时用户早就流失了
  • 很多问题是"偶发性"的,等你手动检查时一切正常

解决方案:自建监控站

在 VPS 上部署 Uptime Kuma(或类似工具),每 30-60 秒检测一次全球访问状况。一旦挂掉,立即通过 Telegram 、Discord 或邮件通知。

监控清单建议

监控项 检测频率 告警方式
HTTP 状态码 60 秒 Telegram 即时通知
SSL 证书到期 每天 提前 14 天预警
服务器资源 5 分钟 CPU/内存超 80% 告警
数据库连接 60 秒 连接失败立即通知

进阶玩法

  • Uptime Kuma 做可用性监控
  • BezelNetdata 做服务器资源监控,Bezel 还挺好用的。Netdata 稍微重点。
  • 两者结合,形成完整的监控闭环

图 4:全天候监控与即时告警闭环

6. 数据主权:独立开发的“最后防线”

  • 痛点:平台依赖风险

    如果你的数据全在 Firebase ,某天账号因为合规问题被封,你的所有努力将瞬间清零。

  • 解决方案:VPS 本地化存储 + 异地备份


    • 数据隔离:数据库文件完全属于你。
    • 自动化备份:编写一个简单的 Cron 任务,每天定时将数据加密并同步到 S3 或你的本地存储。

image.png

7. 独立开发者的资源规划:“1 + N” 策略

针对 2026 年的典型开发场景,我们建议采用以下阵列:

类型 规格建议 核心作用
1 台主领地 2 核 4G 或 4 核 8G 运行 Nginx 、核心数据库、核心产品。
N 台哨兵机 1 核 1G 或更低 运行 Uptime Kuma 监控、小型爬虫、测试环境。
为什么需要分开?
  • 监控服务不应该和被监控的服务在同一台机器——否则机器挂了你也收不到告警
  • 测试环境和生产环境隔离,避免误操作
  • 多台小机器比一台大机器更有弹性

image.png

Reddit 上 Hetzner 被反复提及为"性价比之王":同样的价格,配置通常是美国云服务商的 2-3 倍。缺点是机房主要在欧洲,亚洲访问延迟较高。

咋说呢? 数据库还是很重要的,如果精力有限,就还是用 neon 或者 supabase 之类的。

总结:从“玩票”到“专业”的入场券

拥有 VPS 的那一刻起,你就不再只是一个“写代码的人”,而是一个 “系统的掌控者”。它为你提供了:

  • 确定性:不再受本地环境变化的干扰。
  • 连续性:产品 24 小时独立生存。
  • 商业性:以最低的边际成本支撑业务增长。

正如独立开发圈子里流传的一句话:“你的第一个服务器 IP ,就是你产品的第一张名片。”(我编的)

VPS 入门:为什么独立开发者需要一台 VPS ?( 2026 深度版)

前因:

上次有佬友问如何自动定时同步上游仓库,当时我随手糊了一段脚本,结果发现 bug 满天飞,于是删除了。同时也推荐了 pull 这个工具,但是这个工具的同步比较随机,不可控。
于是就搞了现在这个脚本,支持多仓库、多用户、多分支、多平台通知

食用方法:
fork 仓库,然后根据 README.md 进行配置。
上游仓库:可以是任意公开仓库
目标仓库:可以是任意用户的仓库(需要具备 repo 权限的 token)

目标仓库支持你 fork 别人的,不影响 pr、创建分支等。也可以你自己创建一个空仓然后搬运。

该脚本运行于 GitHub Aactions,运行后的 actions 日志会显示上游仓库地址、目标仓库 owner/repo,但是不会暴露各种 token 等私密信息。可以把仓库设置为私密,不影响同步功能和效果。

推送的消息如下:


📌 转载信息
原作者:
binghe
转载时间:
2026/1/16 17:41:31

然后就发现了问题,用 github 托管镜像的话,国内的服务器拉取镜像速度太慢,各厂商镜像服务又有相应限制,在服务器上挂代理又有一定的风险

故而迁移一份仓库到腾讯新出的平台 CNB 上

提高国内服务器的访问速度,依旧自动更新和构建

(不过感觉腾讯给的免费对象存储额度不太够)

忘了给链接了


📌 转载信息
原作者:
AliverAnme
转载时间:
2026/1/16 12:46:09

混了这么久社区我也是终于三级了啊 (凌晨四点升级)!这几天用 AI 糊出来了一个小玩具,可以配合站里大佬
@F-droid 的项目🎉Gemini Business 2API 来了 | 支持 Docker 一键启动! 使用 Gemini Business 的各个 gemini 模型(大香蕉随便用说是)。

所有需要用到的项目我会在帖子最后给出地址,这里需要搭建的项目为 API 反代Hugging Face 镜像(也可以换成别的,例如 zeabur)和域名邮箱

这里先给出 github 地址,具体的配置详情都在 github 中可自行查阅 希望大家可以帮我点点 star,我在这里感激不尽

GeminiForge

现在来说说项目的具体功能:
通过 github 工作流使用配置的代理节点,域名邮箱和凭证上传地址来自动注册 Gemini Business 账号,获取凭证并上传至 2api 中,可以说是相当方便了。

代理除了常见的 HTTP/SOCKS5 代理,还额外支持 VLESS 代理(塞了个 singbox,这里建议节点用好一点,不然可能打不开网页或者接不到验证码,GitHub 的 ip 无法注册)

vless 支持两种格式,一种是正常的 VLESS URL,另一种就是 YAML 配置

格式一:VLESS URL(推荐)

vless://uuid@server:port?type=tcp&security=reality&sni=example.com&fp=chrome&pbk=xxx

格式二:YAML 配置

{ server: example.com, port: 443, uuid: xxx-xxx, flow: xtls-rprx-vision, ... }

项目设定为每 6 小时自动运行一次,一次注册两个账号并上传凭证,并且支持并发注册,最多 5 并发,这些设置可以通过修改 workflows 中的 register.yml 文件修改。

最后是用到的几位大佬的帖子和项目链接,大家可以自行查看与搭建。

注册机逻辑

API 反代

Hugging Face 镜像

域名邮箱搭建


📌 转载信息
原作者:
starsdream
转载时间:
2026/1/15 18:23:41

HiveMind Actions 是一款基于 Google Jules 的自动审查系统
使用者只需要制定好基础的规则
Google Jules 将会在每次 PR 推送时自动审查推送内容是否正常
如果有问题也会根据规则进行修正

这可以降低手动审查 PR 的频率
并且避免审查者在无意间将不良的 PR 给通过

而且这部分都是基于云端来 Build
核心部分 - Google Labs Jules 是基于云端的 AI coding agent
HiveMind Actions 2.0 - 则是 build 在 GitHub Actions 上
实现全天候的 PR 审查流程

有兴趣的朋友可以玩看看
HiveMind Actions

Google Labs Jules

偷偷说一下,目前我正在进行 APP 限免的板块申请
如果可以的话希望大家支持一下!

请进

【APP 限免】 板块申请


📌 转载信息
原作者:
josenlou
转载时间:
2026/1/15 10:08:30

详情见:GitHub - WeMingT/zaimanhua-auto-chick-in: 基于 GitHub Actions 的再漫画 (zaimanhua.com) 自动签到工具 | Auto check-in tool for zaimanhua.com

支持功能:

功能说明触发时间 (北京)
每日签到自动完成签到任务并领取积分8:00
每日评论在随机漫画下发表评论9:30
每日阅读自动阅读漫画10:00
每日抽奖完成任务并自动抽奖11:00
积分领取任务完成后自动领取积分随任务执行

📌 转载信息
原作者:
klama
转载时间:
2026/1/14 11:03:27

佬友,你如何追踪领域内最新文献?
佬友,你还在靠刷公众号的文献推送碰运气吗?
佬友,你还在等导师给你转发公众号文章吗?
佬友,你需要主动出击!

刚看到我在 L 站科研的帖子,遂把自用的自定义文献订阅项目发出来:

由于纯自用,所以项目中暂时没有 README.md,仅在此做详细说明。

【摘要】
这是一个基于 GitHub Actions 的全自动文献筛选推送工具,根据设定的关键词从关注的期刊 RSS 列表中抓取最新论文并生成一个 RSS 订阅源,可使用 Zotero 接收订阅。

【使用方法】

  1. Star (非必须)
  2. Fork 我的项目并删除 filtered_feed.xml 文件
  3. journals.dat 中编辑你感兴趣的期刊 RSS 链接,一行一个
  4. keywords.dat 中填入关键词,一行一个,支持 AND 检索式
  5. 如果担心关键词泄露你的研究领域 /idea,可以不使用 keywords.dat ,进行如下操作:
    • 进入仓库的 SettingsSecrets and variablesActions
    • 点击 New repository secret
    • NAME 中填 RSS_KEYWORDS
    • Secret 中填关键词,一行一个,支持 AND 检索式
  6. 进入 SettingsPages,在 Build and deployment
    • Source 选择: Deploy from a branch
    • Branch 选择: main 分支的 /(root) 目录
    • SAVE
  7. 进入 Actions 页面,如果有 "Workflows aren’t being run on this forked repository" 提示,则点击 I understand my workflows, go ahead and enable them 按钮
  8. 点击 Auto RSS FetchRun workflowRun work flow 手动运行一次生成 filtered_feed.xml 文件,后续每 8 小时会自动运行一次
  9. 打开你的 RSS 管理软件,这里以 Zotero 为例:
    • 点击文件新建文献库新建订阅从网址
    • 网址填写 https://{你的github用户名}.github.io/paper-feed/filtered_feed.xml
    • 标题随意填写
    • 高级选项自定义,更新订阅时间建议小于等于 8 小时
  10. 享受你的阅读


一次配置,终身使用


📌 转载信息
原作者:
JarvisTown
转载时间:
2026/1/8 12:10:01

在 Lunes.host 上使用 Node.js Generic 方式部署 Uptime Kuma 监控面板

功能特性

  • 每天定时自动备份(默认凌晨 4 点)
  • 自动清理超过 5 天的旧备份
  • 首次启动自动恢复最新备份
  • 支持 ZIP 加密备份(可选)
  • WebDAV 云端存储,数据安全可靠

项目结构

/home/container/
├── package.json
├── .nvmrc
├── config.sh          # ⚙️ 配置文件(需修改)
├── start.sh           # 🚀 启动脚本(需 755 权限)
└── scripts/
    ├── backup.sh      # 💾 WebDAV 备份(需 755 权限)
    └── restore.sh     # 📥 WebDAV 恢复(需 755 权限) 

快速开始

查看端口

在 Lunes.host 控制面板查看分配给你的端口号:

上传文件并配置权限

上传项目文件:

为脚本添加 755 执行权限:


需要添加权限的文件:

  • start.sh
  • scripts/backup.sh
  • scripts/restore.sh

修改配置文件

编辑 config.sh,根据你的实际情况修改:

#!/bin/bash # ============================================ # Uptime Kuma 配置文件 # ============================================ # 端口号(改为你的实际端口) export PORT="${PORT:-2114}" export TZ="Asia/Shanghai" # 预构建包下载地址(无需修改) export KUMA_DOWNLOAD_URL="https://github.com/oyz8/action/releases/download/2.0.2/uptime-kuma-2.0.2.tar.gz" # ============================================ # WebDAV 备份配置 # ============================================ export WEBDAV_URL="https://zeze.teracloud.jp/dav/backup/Uptime-Kuma/" export WEBDAV_USER="你的用户名" export WEBDAV_PASS="你的密码" # 备份加密密码(可选,留空则不加密) export BACKUP_PASS="" # 每天备份时间(0-23 小时制) export BACKUP_HOUR=4

# 备份保留天数 export KEEP_DAYS=5

WebDAV 推荐: 本项目使用 InfiniCLOUD (Teracloud) 作为备份存储

注册时输入推荐码 PPMZC,可在 20GB 基础上额外获得 5GB 存储空间!

配置启动命令

在 Startup 设置中填入:

npm start 

启动服务

点击 Start 按钮启动:

手动操作 (在启动命令改为下面命令)

# 手动执行备份
bash scripts/backup.sh

# 手动恢复最新备份
bash scripts/restore.sh

# 恢复指定备份文件
bash scripts/restore.sh lunes-host-backup-2024-12-26-10-30-00.zip

注意事项

  • 必须使用 Node.js Generic 方式部署
  • 首次启动需要下载预构建包,请耐心等待
  • 确保 WebDAV 目录已提前创建
  • 脚本文件必须有执行权限(755)

许可证

MIT License


📌 转载信息
原作者:
oyz
转载时间:
2025/12/27 00:30:54