为github ci 添加缓存机制

[Guozhanxin]

目前 RT-Thread 仓库为了保证代码的正确性，基本每个PR都会编译一遍所有的bsp，其中环境安装是最耗时的部分。如果可以利用 github 的cache机制，就可以极大的加快仓库ci的执行效率。

参考

• https://mrseawave.github.io/blogs/articles/2021/12/17/github-actions-cache/
• https://docs.github.com/en/enterprise-cloud@latest/rest/actions/cache

[a1012112796]

不知道 github action 是否像drone ci 一样支持使用自定义的 docker 镜像来运行ci, 如果可以，那就可以打包一个专门的镜像用于构建测试 rt-thread。 示例: https://gitea.com/gitea/test-env/src/branch/master/Dockerfile

[mysterywolf]

现在貌似CI每测试一个BSP都需要将ARM或者RISC-V的编译链下载安装一遍，能不能提前一次下载好，直接编译。

[a1012112796]

尝试了一下基于 docker 的方案，但提速效果不明显，每次的docker 镜像似乎还是重新下载的: https://github.com/a1012112796/rt-thread/runs/7194339923?check_suite_focus=true

对比 当前: 使用 docker 后

[tuduweb]

rt-thread主分支太大了，bsp目录占用了太多的空间，每次在action里面checkout都需要花费大量的时间，如上图每次checkout都要半分钟多，这部分看起来不是用缓存好去解决的。

[supperthomas]

rt-thread主分支太大了，bsp目录占用了太多的空间，每次在action里面checkout都需要花费大量的时间，如上图每次checkout都要半分钟多，这部分看起来不是用缓存好去解决的。

有什么好的想法和建议么？你觉得怎样做会比较好？

[tuduweb]

rt-thread主分支太大了，bsp目录占用了太多的空间，每次在action里面checkout都需要花费大量的时间，如上图每次checkout都要半分钟多，这部分看起来不是用缓存好去解决的。

有什么好的想法和建议么？你觉得怎样做会比较好？

要不 按工具链等要求 执行对应的一系列的bsp检测。也就是在一个机器里检测N次build。 要不就是拆单个bsp出去了，不过这个可能不太现实。

[supperthomas]

https://club.rt-thread.org/ask/article/b3d7172e2b37cd0a.html

[supperthomas]

缓存机制还是需要的，可以避免一些频繁下载出错的情况。

[mysterywolf]

我以为这个是上面的PR已经解决了😂

[supperthomas]

我以为这个是上面的PR已经解决了😂

感觉应该已经解决了耗时的问题。