如何在当前pipeline运行中获取同一条pipeline上一次运行的输出结果

需求核心为实现条件缓存失效：部分场景复用已生成的hash值，其他场景生成新hash，新值需持久化供后续所有pipeline运行读取，直到下次更新为止。

通用实现逻辑 #

• 第一步：选择跨运行可读写的持久化存储介质，可选CI工具内置缓存、对象存储、代码仓库专用配置分支/文件等，小体量场景优先选CI自带缓存功能，无需额外搭建服务
• 第二步：pipeline启动阶段先读取存储的上一次hash值，赋值为当前运行的全局环境变量PREV_HASH
• 第三步：执行自定义条件判断逻辑，决定本次是否需要更新hash：
  • 无需更新时，直接复用PREV_HASH作为本次运行的hash输出，不覆盖原有存储
  • 需要更新时，执行原有hash生成逻辑得到新值，将新值作为本次输出的同时覆盖存储中的旧值

示例（GitHub Actions场景） #

jobs:
  hash-handle:
    runs-on: ubuntu-latest
    steps:
      # 读取历史hash缓存
      - name: Load previous hash cache
        uses: actions/cache@v4
        with:
          path: ./current-hash.txt
          key: fixed-pipeline-hash-storage # 此处key必须固定，不能加动态变量
      
      # 提取上一次运行的hash值
      - name: Get previous hash
        id: get-prev
        run: |
          if [ -f ./current-hash.txt ]; then
            echo "prev_hash=$(cat ./current-hash.txt)" >> $GITHUB_OUTPUT
          else
            echo "prev_hash=initial_value" >> $GITHUB_OUTPUT
          fi
      
      # 自定义判断是否需要更新hash，此处为示例逻辑，可替换为自身业务规则
      - name: Check hash update requirement
        id: check-update
        run: |
          # 示例：当配置文件内容变更时触发hash更新
          if [ $(git diff HEAD~1 HEAD ./config.yaml | wc -l) -gt 0 ]; then
            echo "need_update=true" >> $GITHUB_OUTPUT
          else
            echo "need_update=false" >> $GITHUB_OUTPUT
          fi
      
      # 生成新hash并更新存储
      - name: Generate new hash
        if: steps.check-update.outputs.need_update == 'true'
        run: |
          # 替换为自身hash生成逻辑
          NEW_HASH=$(sha256sum ./config.yaml | awk '{print $1}')
          echo $NEW_HASH > ./current-hash.txt
          echo "CURRENT_RUN_HASH=$NEW_HASH" >> $GITHUB_ENV
      
      # 复用历史hash
      - name: Reuse existing hash
        if: steps.check-update.outputs.need_update == 'false'
        run: echo "CURRENT_RUN_HASH=${{ steps.get-prev.outputs.prev_hash }}" >> $GITHUB_ENV

注意事项 #

• 存储介质必须支持跨pipeline运行共享读写，禁止使用运行实例的临时存储空间，否则运行结束后数据会被清空
• 需为pipeline运行账号配置存储介质的读写权限，避免写入失败导致新hash无法持久化，后续运行始终读取旧值
• 高并发触发pipeline的场景需加分布式锁，避免多个运行实例同时写存储导致hash值被错误覆盖，低频率触发的小团队场景可忽略该点

内容的提问来源于stack exchange，提问作者The Fool