Workflows: Ensure Geodat exists

[Meo597]

test和build流程依赖geodat，但无法确保它们存在，只是简单的从cache恢复

因为这些资源依赖scheduled-assets-update.yml定时下载，有时fork或开新分支时它没能被触发就会导致如下错误

[Meo597]

Test失败与此PR无关

[RPRX]

重新触发了

[RPRX]

看看 @KobeArthurScofield 有没有想法

[KobeArthurScofield]

看了下……

建议：其实做成直接调用 scheduled-assets-update 会更好一些的，而且这个调用更加应该在 build 的 job 之前放置一个专门的 job。

首先是在 build 里面直接检查并下载的话，空 cache 状态非常容易触发 GitHub 的速率限制导致随机失败问题（大概 30 个 job 以上，每个 job 都下载，加上短时间调用两三次就能触发），以前就发生过，所以才用了 cache 并且在下载后 save cache 以供一次下载反复调用避免限制问题。

后面将 检查下载保存 独立出来定时运行是让这个过程自动化操作，而且在能保证最新的条件下这个过程尽可能懒，避免 Actions 列表刷屏。目前空 cache 问题解决方式是手动运行 assets-update，不过能自动化解决最好。

[Meo597]

是的我也觉得这样写比较丑，主要是代码没能复用，但是内耗了一下发现没有优雅的解决办法

因为github的action是异步的，没有办法简单粗暴的支持：同步阻塞等待别的workflow执行完毕后，再继续此workflow

除非调github的api，考虑到本来就是简单的下载俩文件，没必要搞这么麻烦
这是一个取舍问题

[Meo597]

然后如果build test等都调用scheduled-assets-update会导致Actions列表刷屏

不过ratelimit这块确实可以加个：若真的下载了文件，那就回写到cache

@KobeArthurScofield 你咋看

[KobeArthurScofield]

看了下目前更新一次 assets 需时大概十来秒，编译一次至少 30 秒，加上前面拉代码设置 Go 之类的，不考虑 edge case 以及可能的并发执行 workflow 限制的话异步也是可以的。

然后建议这样：

jobs:
  check-assets:
    # assets 相关流程

  build:
    # 应该有个 require 在这里要求跑完上一个 job 再执行这个 job
    # 构建流程

检查了发现没有 geodata 或者 build_assets 再调用，可以保证不会突然检查三十多次的问题

[KobeArthurScofield]

感觉 GitHub 最近为了反爬已经杀红眼了，速率限制严格不少，现在尽量降低 cURL 拉取内容的频次还是有必要的

[Meo597]

github的设计也很丑，下面代码不能用，因为key不完全匹配不算数，记录一下。以后说不定会改

https://github.com/actions/cache/tree/v4/restore

Note cache-hit will be set to true only when cache hit occurs for the exact key match. For a partial key match via restore-keys or a cache miss, it will be set to false.

name: Test

on:
  push:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  check-assets:
    runs-on: ubuntu-latest
    steps:
      - name: Restore Geodat Cache
        id: restore-geodat-cache
        uses: actions/cache/restore@v4
        with:
          path: resources
          key: xray-geodat-
          enableCrossOsArchive: true
      - name: Trigger Asset Update Workflow if Cache Miss
        if: steps.restore-geodat-cache.outputs.cache-hit != 'true'
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const { owner, repo } = context.repo;
            await github.rest.actions.createWorkflowDispatch({
              owner,
              repo,
              workflow_id: 'scheduled-assets-update.yml',
              ref: context.ref
            });
            console.log('Triggered scheduled-assets-update.yml due to missing assets on branch:', context.ref);
      - name: Sleep for 60 seconds if Cache Miss
        if: steps.restore-geodat-cache.outputs.cache-hit != 'true'
        run: sleep 60

  test:
    needs: check-assets
    permissions:
      contents: read
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [windows-latest, ubuntu-latest, macos-latest]
    steps:
      - name: Checkout codebase
        uses: actions/checkout@v4
      - name: Set up Go
        uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
          check-latest: true
      - name: Restore Geodat Cache
        uses: actions/cache/restore@v4
        with:
          path: resources
          key: xray-geodat-
          enableCrossOsArchive: true
      - name: Test
        run: go test -timeout 1h -v ./...

[Meo597]

@RPRX @KobeArthurScofield
完事了

因为github的api限制，目前仍然需要手工检查文件是否存在，这样很丑，但能用
原因见上一条

[KobeArthurScofield]

大体上差不多了

在想要不要这样：调用更新只要主要 release.yml 调用就行，其它的发现没有缓存就先 sleep，压低调用次数避免刷出四个 assets update 以及某些时候触发限制。

等 120 秒会不会有点长因为大部分情况数十秒已经完事，不过考虑到 cache 已经没了也算是种异常情况，还可以接受。

github的设计也很丑

因为github的api限制

我们都有相近的吐槽

[Meo597]

两个release和test是必定一起运行的吗，有没有仅运行某个的情况

那可以让test触发，另外两个傻等就行了
设120主要考虑这种cache miss频率低，怕action有时有延迟，翻车浪费五分钟，宁愿多等会儿
也可以改低

[KobeArthurScofield]

有没有仅运行某个的情况

所有 release.yml 可以手动运行，另外发 release 版本更新的时候不运行 test （这个可以忽略）

设120主要考虑这种cache miss频率低，怕action有时有延迟，翻车浪费五分钟，宁愿多等会儿

那可以

[Meo597]

按log的时间戳计算
资源下载的job一般15s
触发这个job需要8~12s

感觉没那么快，我F5都按烂了，可能更新到网页上总是滞后的
改到90了，应该没啥问题，以后等人反馈

[KobeArthurScofield]

没什么问题的话我觉得 ok

[yuhan6665]

Thanks both for great collab!

[Meo597]

事实证明 github 的 cache 十分不可靠
不能过度依赖它，应该有一个回退机制 —— 缓存恢复失败应 curl 下载
不过这又可能导致各不同平台的编译产物中 geodat 版本不一致问题，虽然不是什么大事

今晚 github 官方有 bug，cache 页面狂按 F5 有可能显示出已被删除的 cache
然后 restore 步骤，可能成功或失败

只是记录一下这个问题，如果以后频发再考虑 curl

[KobeArthurScofield]

Github 抽风删 cache 已经不是第一次了，但是不知道为什么会偶发这个问题

不过这又可能导致各不同平台的编译产物中 geodat 版本不一致问题，虽然不是什么大事

好消息是目前用的 Loyalsoldier 的源问题不是很大，只要不是大清早发版

如果是用 v2fly 官方源倒是真的有机会会发生这个问题，他们合一个 pr 发一次版，但是合 pr 是随机时间发生的