Workflows: Remove duplicate processes in release-win7.yml

[o0HalfLife0o]

prepare环节是为了更新geodat才存在的，主要的release.yml有就够了，其他workflow直接用，不需要再做重复工作

[RPRX]

这个执行顺序有保证吗，@KobeArthurScofield 把 prepare 抽出来单独放一个文件吧

[KobeArthurScofield]

这个执行顺序有保证吗

仅限同一个 action 文件里面，不同 action 之间的只要能触发就不好保证，而且也没有阻塞等待的方法

[o0HalfLife0o]

这个执行顺序有保证吗，@KobeArthurScofield 把 prepare 抽出来单独放一个文件吧

#1711 只有以前第一次加prepare时因为还没geodat缓存可能会出问题，现在缓存都很多了，不会出问题的
当初搞这个prepare就是为了更新geodat，因为每一次触发action都是上百次的同时更新geodat文件，触发github限制，导致大量失败，yuhan修了好几都没搞好，所以引入了action/cache来传递geodat

[KobeArthurScofield]

查文档有两种思路解决这个问题：

1. 将 prepare 抽出来，改成用 schedule 触发器定时运行更新，所有 build 直接用缓存就好
2. 将 prepare 抽出来，所有 build 改成 workflow_run (completed) 触发，或者改成 workflow_call 由 prepare 拉起

实现上应该不难

[RPRX]

话说不同 yml 间执行环境竟然不是隔离的？令人意外

[KobeArthurScofield]

话说不同 yml 间执行环境竟然不是隔离的？

每次都会清空，不过 prepare 里面做了 save cache 操作手动保存了 geodata 文件，build 之后 restore cache 就可以恢复这些文件

[KobeArthurScofield]

不同 action 之间的只要能触发就不好保证

准确说是用同样的触发器在同样条件下运行的会不好保证，比如启动时间有差异，或者因为实际同时可以跑的 job 有限制，数量一多就会开始排队，等等。
直接删掉其它 build 的 prepare 有可能会发生还没对 geodata 检查更新就已经复制进去的情况，只是按照目前的 actions 规模来看这个可能性很小（从开始到编译结束大概三十多秒，而检查 geodata 更新只需数秒即可）。