由于某种申必原因，我看了眼github actions的资源限制，发现了些很有意思的东西🤔
比如它一个白嫖账号可以跑的并行runners数量居然不是5或者10，而是20🤔但更有意思的是除了每个job最多六小时这种陈词滥调外，我还发现了一个一个一个有意思的玩意：每个workflow的最高运行时间长达35天🤔
至此我才意识到一个workflow里面不见得只能跑一个job，尽管我的各种脚本里面习惯性地只安排了一个🤔换句话说我完全可以安排多个jobs，比如考虑到sexart系试用号只能试用24小时，我可以安排四个jobs，将其串成一串来跑相同的脚本四遍（需要设置好这些jobs的依赖关系，不然它们就会并行运行，那肯定不是我想要的），这样我是不是就可以免得每6小时盯着看它搞完了没有（确信🤔
那么在这种情况下，下一个job（是一台全新的虚拟机）如何继承上一个job的maindb进度？🤔答案其实相当简单，我只需要每次搞完一个链接后除了照例将当前进度打包进guilded drive外，我还可以直接修改放在pikapod上用来下载到actions机器的maindb，这样下个job拖这些maindb开始处理时，自然拖的就是已经处理过一部分的力（确信🤔而如何修改它们呢？只需要一个一个一个简单的php脚本，外加一句curl文件上传语句，就可以搞定，反正比我之前用的sftp方便多力（确信🤔
接下来我需要写一个测试用例，一个只包括四行的maindb，还有一个每次for只出一行结果的脚本🤔测试下来基本上符合预期，第一行处理完成后这个job结束运行，可以看到下一个job的确从第二行开始处理，而放在pikapod上的maindb也便乘了第一行有链接🤔那么接下来两个基本上不用测力🤔
或者我可以将脚本里的只限处理一行这句删掉，看第三个job处理完剩下两个链接后，第四个job会做什么🤔它做的无非是打出四行红字，都已经处理过一遍力，然后退出（确信🤔