影刀RPA GitHub Actions自动化：CI-CD流水线自运维

影刀RPA GitHub Actions自动化CI/CD流水线自运维作者林焱 | 适用人群影刀RPA新手 | 难度★★★☆☆一、什么情况用这个团队用GitHub Actions跑CI/CD每天早上第一件事就是打开GitHub看昨晚的构建有没有挂、测试有没有失败。挂了还得手动触发重跑——一天中最浪费时间的例行公事。用影刀RPA定时拉取GitHub Actions运行状态 → 汇总成日报 → 构建失败自动重试 → 通过企微/钉钉推送给团队。你只管打开消息看一眼别的机器人帮你干了。实际场景开发团队的CI/CD状态监控、开源项目的自动化运维、多仓库构建状态统一汇总。这篇文章能解决的问题调用GitHub API查询Actions运行状态自动汇总多个仓库的构建结果构建失败自动触发重跑生成每日CI/CD健康报告二、怎么做2.1 准备GitHub Token拼多多店群自动化上架方案在GitHub → Settings → Developer settings → Personal access tokens → Generate new token (classic)勾选repo和workflow权限。2.2 影刀主流程┌──────────────────────────────────────────────┐ │ ① 【执行Python代码】 │ │ 调用GitHub API拉取所有仓库的Actions状态 │ │ ↓ │ │ ② 【执行Python代码】 │ │ 汇总统计成功/失败/进行中的数量 │ │ ↓ │ │ ③ 【遍历列表】 │ │ 对失败的workflow自动重跑 │  │ ↓ │ │ ④ 【写入Excel】 │ │ 生成CI/CD日报 │ │ ↓ │ │ ⑤ 【发送企业微信消息】 │ │ 推送汇总通知 │ └──────────────────────────────────────────────┘2.3 核心代码步骤①查询Actions运行状态importrequestsimportjsonfromdatetimeimportdatetime,timedelta# 配置 GITHUB_TOKENghp_xxxxxxxxxxxx# 你的Personal Access TokenHEADERS{Authorization:ftoken{GITHUB_TOKEN},Accept:application/vnd.githubjson,}# 要监控的仓库列表REPOS[myorg/frontend-app,myorg/backend-api,myorg/data-pipeline,]defget_latest_workflow_runs(owner,repo,since_hours24):获取仓库最近的workflow运行记录urlfhttps://api.github.com/repos/{owner}/{repo}/actions/runs# 筛选最近24小时的运行since(datetime.utcnow()-timedelta(hourssince_hours)).isoformat()Zparams{per_page:50,# 每页最多50条created:f{since},}responserequests.get(url,headersHEADERS,paramsparams,timeout30)ifresponse.status_code!200:print(f查询失败{repo}→{response.status_code}{response.text})return[]dataresponse.json()runsdata.get(workflow_runs,[])# 提取关键信息result[]forruninruns:result.append({repo:f{owner}/{repo},workflow_name:run.get(name,),run_id:run.get(id),status:run.get(status),# queued/in_progress/completedconclusion:run.get(conclusion),# success/failure/cancelledbranch:run.get(head_branch,),trigger:run.get(event,),# push/pull_request/schedulecreated_at:run.get(created_at,),url:run.get(html_url,),})returnresult# 批量查询 all_runs[]forrepoinREPOS:owner,repo_namerepo.split(/)runsget_latest_workflow_runs(owner,repo_name)all_runs.extend(runs)print(f{repo}: 查到{len(runs)}条运行记录)outputjson.dumps(all_runs,ensure_asciiFalse)步骤②汇总统计importjsonfromdatetimeimportdatetime runsjson.loads(all_runs_data)# 从上一步传入# 分类统计stats{success:0,failure:0,cancelled:0,in_progress:0,queued:0,failed_runs:[],# 失败的详情}forruninruns:ifrun[status]completed:conclusionrun.get(conclusion,unknown)ifconclusioninstats:stats[conclusion]1ifconclusionfailure:stats[failed_runs].append(run)else:ifrun[status]instats:stats[run[status]]1# 生成汇总报告report{report_time:datetime.now().strftime(%Y-%m-%d %H:%M:%S),total_runs:len(runs),success:stats[success],failure:stats[failure],cancelled:stats[cancelled],in_progress:stats[in_progress],failed_details:stats[failed_runs],}summaryjson.dumps(report,ensure_asciiFalse)print(f成功:{stats[success]}失败:{stats[failure]}进行中:{stats[in_progress]})步骤③自动重跑失败的workflowimportrequestsimportjsonimporttime GITHUB_TOKENghp_xxxxxxxxxxxxHEADERS{Authorization:ftoken{GITHUB_TOKEN},Accept:application/vnd.githubjson,}defrerun_workflow(owner,repo,run_id):重新运行失败的workflowurlfhttps://api.github.com/repos/{owner}/{repo}/actions/runs/{run_id}/rerunresponserequests.post(url,headersHEADERS,timeout30)ifresponse.status_code201:return{success:True,message:f重跑成功:{owner}/{repo}run#{run_id}}else:return{success:False,message:f重跑失败:{status_code}{response.text[:200]},}# 从失败列表重跑 failed_runsreport.get(failed_details,[])rerun_results[]forruninfailed_runs:partsrun[repo].split(/)owner,repoparts[0],parts[1]resultrerun_workflow(owner,repo,run[run_id])rerun_results.append(result)# GitHub API有速率限制重跑之间间隔1秒time.sleep(1)rerun_outputjson.dumps(rerun_results,ensure_asciiFalse)print(f请求重跑{len(failed_runs)}个失败的workflow)步骤④⑤生成日报并推送影刀中【写入Excel】 Sheet1「运行概览」→ 写入stats汇总数据 Sheet2「失败详情」→ 写入failed_runs列表 Sheet3「重跑结果」→ 写入rerun_results 【发送企业微信消息】 Markdown格式 GitHub CI/CD 日报{report_time} 总运行数{total_runs} ✅ 成功{success} ❌ 失败{failure}已自动重跑 ⏳ 进行中{in_progress} 失败详情 {每条失败记录的仓库workflow名称链接}三、有什么坑坑1GitHub API速率限制未认证的请求每小时只能60次使用Token后可以到5000次/小时。但如果你监控几十个仓库查询频率高的话还是可能超限。应对措施defcheck_rate_limit():检查API剩余配额urlhttps://api.github.com/rate_limitresponserequests.get(url,headersHEADERS)dataresponse.json()remainingdata[rate][remaining]reset_timedata[rate][reset]ifremaining100:print(f⚠️ API配额即将耗尽剩余{remaining}次重置时间{reset_time})returnFalsereturnTrue# 在批量查询前检查ifnotcheck_rate_limit():print(配额不足跳过本次执行)exit()坑2workflow可能不存在或改名仓库改名、workflow文件删除后API返回的workflow列表可能意想不到TEMU店群如何管理运营defget_workflow_runs_safe(owner,repo):安全查询处理异常try:returnget_latest_workflow_runs(owner,repo)exceptrequests.exceptions.Timeout:print(f超时{owner}/{repo})return[]exceptExceptionase:print(f未知错误{owner}/{repo}-{e})return[]坑3重跑幂等性问题有些workflow不支持重复运行比如已经合并的PR的workflow重跑会报错。处理方式ifresponse.status_code403:# 403可能是不允许重跑权限问题或workflow状态不允许return{success:False,message:f不允许重跑可能已合并或关闭}elifresponse.status_code422:# 422通常是状态不允许return{success:False,message:workflow状态不允许重跑}坑4多个workflow同时重跑导致排队GitHub Actions有并发限制一次性重跑10个workflow可能导致后面几个排队很久。加上并发控制importconcurrent.futures# 最多同时重跑3个withconcurrent.futures.ThreadPoolExecutor(max_workers3)asexecutor:futures[]forruninfailed_runs:fexecutor.submit(rerun_workflow,...)futures.append(f)forfinconcurrent.futures.as_completed(futures):print(f.result())坑5Token权限不够如果用的是Fine-grained token细粒度令牌需要确保勾选了目标仓库权限包含Actions: Read and Write用Classic token更简单勾上repo和workflow就行。总结影刀 GitHub Actions API 让CI/CD监控从「人工刷新网页」变成「机器人自动巡检 自动重试 定时推送」。关键是控制API调用频率、处理重跑的边界情况、Token权限配足。