GitHub Actions如何实现持久化状态？无需持续运行VM且防并行冲突

针对你需要在多次GitHub Action调用间持久化状态、避免持续运行高成本VM且防范并行冲突的需求，以下是几种实用方案：

1. 仓库内Git存储状态文件 #

直接在代码仓库中维护状态文件（如state.json），通过Git提交实现状态持久化：

• 操作流程：步骤中拉取仓库，读取状态文件并修改，然后提交推送回仓库。
• 冲突防范：优先使用GitHub API的文件更新接口（而非原生Git命令），接口会验证文件的当前SHA哈希，只有本地版本与远程一致时才允许更新。若遇并行冲突，在步骤中添加重试逻辑，重新拉取最新状态后再尝试修改提交。
• 优势：零额外成本，状态变更可通过Git历史追溯，无需维护外部服务。
• 注意：需使用具备仓库写入权限的Token（如GITHUB_TOKEN），避免频繁小提交导致仓库历史冗余。

2. 依托GitHub Releases存储状态数据 #

将状态打包为小文件，作为GitHub Release的附件（asset）存储：

• 操作流程：更新状态时，通过API创建新Release或更新现有Release的附件；读取状态时，下载最新Release的对应附件。
• 冲突防范：使用带时间戳的唯一Release标签，确保每次更新生成独立的Release，读取时取最新标签的Release即可避免覆盖冲突。也可通过API验证Release的当前状态，冲突时重试更新。
• 优势：状态与版本发布关联，存储稳定不会被自动清理，适合和版本绑定的场景。

3. 轻量级外部键值存储服务 #

选用低成本/免费的键值存储服务（如Redis Cloud免费套餐、AWS DynamoDB免费层级）：

• 操作流程：在Action步骤中调用服务API读取、写入状态数据。
• 冲突防范：利用服务的原子操作特性，比如Redis的SETNX（仅当键不存在时设置）、DynamoDB的条件更新，确保同一时间只有一个步骤能成功更新状态。
• 优势：操作高效，适合频繁更新的状态场景，无需持续运行VM，按需调用即可。
• 注意：需在GitHub Secrets中存储服务的访问凭证，保障数据安全。

4. 动态更新GitHub Environment Secrets #

若状态为单一字符串，可通过GitHub API动态更新Environment Secrets来存储状态：

• 操作流程：调用API读取当前Secret值，修改后更新该Secret。
• 冲突防范：在状态中加入版本号，更新时验证当前版本，若版本不匹配则重试，避免并行覆盖。
• 优势：依托GitHub内置功能，无需额外服务，状态加密存储安全性高。
• 注意：Secret更新有频率限制，不适合频繁变更的状态场景。

内容的提问来源于stack exchange，提问作者Simon Richter