在gitea官方release 3.0.0版本action的blog中提到，他们在此版本中引入了cache service v2，可直接支持actions/upload-artifact, actions/download-artifact，不再需要使用适用于gitea的fork版本了。我打算借着这个机会升级一下我的工作流。

我的runner原本运行在家里云上，是一个完整的虚拟机，网络时有波动而且可用性也没有保证。因此我专门又在云服务商那买了一台境内的vps用作某些需要访问国内服务的工作流，比如我将博客迁移到edgeone pages (现在应该叫edgeone makers)，将博客成本降到最低。

至于为什么非要一个境内的vps，只能说经过多次测试，在境外的runner部署中国站的edgeone项目的上传速度非常慢，极易导致超时从而构建失败。因此再三考虑后，在不专门写一个特化edgeone构建服务的前提下，还是直接弄一个境内vps部署action泛用性更强一些。

但是境内vps带来一个新的问题：工作流基本都需要托管在GitHub上的action，只是克隆的话倒是还好，但是有些action还会从release下载东西，比如神奇的actions/setup-node。即使它留了一个镜像地址的配置，设置后也基本没法用，真的很诡异。导致在境内vps部署nodejs相关工作流真的很麻烦。让我有一阵都在考虑搬到比如woodpecker-ci/woodpecker这种第三方CI了。

目前的打算是尽量将构建任务放在境外runner，只把需要境内服务的最后一步——比如上传，放在境内runner上完成。它们是不同的job，因此相互的数据传输就用artifact功能。同样为了尽量少地让境内runner依赖GitHub，我把download-artifact镜像到私人gitea实例了。万幸境内runner还能流畅访问我的私人gitea。也幸亏标准的runner镜像包含了一个nodejs运行时可以直接安装edgeone CLI，不必强制使用setup-node。

经过测试，以下版本的action可正常用于我的环境（gitea v1.27.2/gitea runner v3.1.0）：

• upload-artifact@v7.0.1
• download-artifact@v8.0.1

有一说一，可能某种情况下还真是用gitea-upload-artifact这种fork版本更稳定，毕竟download-artifact我就遇到过v7版本不能用但是v8版本才能用的情况，但是博客里说比v4新就能用。如果未来感觉这个不稳定的话我应该及时切换到适配了gitea的fork版本去。