跳转到内容
Yuuki学习手记
GitHub

第一班:让 Issue 自己来报到

先给夜班装一块小看板:按一下运行,仓库里的 Issue 就带着编号、标题和链接排到你面前。这一班的成果是一份 Actions 运行摘要,不需要 AI Key。

做完再把手动按钮换成定时启动,你就摸到了夜班的第一个机关:一个事件怎样唤起任务,把结果送到能看见的地方。

选一个你有管理权限、已经启用 Issues 与 Actions 的练习仓库,先写一个小 Issue。

在该仓库创建 .github/workflows/issue-scan.yml,复制下面的内容,提交到默认分支:

name: 🍀 看一眼 Issue
on:
workflow_dispatch:
schedule:
- cron: '15 18 * * *'
permissions:
issues: read
jobs:
scan:
runs-on: ubuntu-latest
timeout-minutes: 5
env:
GH_TOKEN: ${{ github.token }}
GH_REPO: ${{ github.repository }}
steps:
- name: 读取全部未关闭的 Issue
shell: bash
run: |
gh api --paginate "repos/$GH_REPO/issues?state=open&per_page=100" \
--jq '.[] | select(has("pull_request") | not) | {number, title, url: .html_url}' \
> issues.jsonl
{
echo '## 🍀 今天的 Issue'
echo
echo "共 $(jq -s 'length' issues.jsonl) 个未关闭的 Issue。"
echo
echo '```json'
cat issues.jsonl
echo '```'
} >> "$GITHUB_STEP_SUMMARY"

这里的文件内容是教学示例,需要你放入练习仓库后才会生效。

进入 GitHub 仓库的 Actions → 🍀 看一眼 Issue → Run workflow,选择默认分支并运行。结束后打开这次运行的摘要,能看见 Issue 的编号、标题和链接就完成了。

如果没有 Issue,会显示 0;这是正常结果。手动运行工作流

配置在这个实验里的含义
workflow_dispatch允许你先手动点击运行
schedule之后按时间自动运行
runs-on: ubuntu-latest使用 GitHub 提供的 Linux 执行环境
issues: read本次任务只需要读取 Issue
--paginate继续读取下一页,避免只拿到第一页
GITHUB_STEP_SUMMARY把结果放进这次运行的摘要

仓库的 Issues API 也会返回 PR,所以示例过滤掉带 pull_request 字段的记录。github.token 是 GitHub 为工作流提供的令牌,传给 GH_TOKEN 后,GitHub CLI 才能以这次任务的权限访问仓库。Issues API、GitHub CLI 分页、工作流令牌

15 18 * * * 使用默认 UTC 时间,对应北京时间每天 02:15。自动触发需要工作流存在于默认分支;GitHub 的调度可能延迟,不能把它当作精确到分钟的闹钟。定时触发规则

  • 找不到 Run workflow:确认文件已在默认分支,且包含 workflow_dispatch。
  • 读取被拒绝:确认目标是同一仓库、Issues 已开启、组织允许 Actions,且工作流声明了 issues: read。
  • 没有按时出现记录:先手动运行;再检查 Actions 是否启用以及默认分支上的定时配置。公开仓库长期没有活动时,计划任务可能自动停用。

想再戳一下它:新增一个标题容易认出的练习 Issue,重新运行,看看清单是否更新;没有 Issue 时,也看一眼 0 的结果。这样就把“读到了什么”对上了。

摘要里出现清单,这一班就交付了。 下一次再来搭手修一个小问题。

示例状态:已在本地检查 YAML、Shell 语法与固定数据的过滤逻辑;尚未提交到远端运行。