Open Ryuchen opened 4 years ago
第一次遇见这种,你用的是master还是dev分支?重试一次还会出现这样的错误吗?错误是一开始编译就出现还是编译过程中出现的?
我是在编译过程中,用的master分支,我编译的X86固件本身就比较大,不知道是不是插件太多的缘故,我本地编译的话,需要23G的空间,用的是master分支
编译到哪一步出的问题?
compile 那个步骤出现的问题
这是我在dev和sample分支目前用的cleanup.sh
echo "Deleting files, please wait ..."
sudo rm -rf /usr/share/dotnet /etc/apt/sources.list.d/* /var/cache/apt/archives /usr/local/share/boost /usr/local/go* /usr/local/lib/android /opt/ghc
sudo swapoff /swapfile
sudo rm -f /swapfile
docker rmi "$(docker images -q)"
sudo -E apt-get -q purge azure-cli zulu* hhvm llvm* firefox google* dotnet* powershell openjdk* mysql*
多删除了一些文件,你可以照此修改。
dev分支我一直没来得及合并到master,因为变动比较大,README一直没时间写完整
嗯,我昨天查看了你的源码,然后把这段加上了,但是还是出现了问题,不过这次是在push 到docker hub时出现问题了 麻烦您看下我的actions
https://github.com/Ryuchen/lede/runs/492193751?check_suite_focus=true
查了一下,好像是整个workflow的时间超过了6个小时
这是我在dev和sample分支目前用的cleanup.sh
echo "Deleting files, please wait ..." sudo rm -rf /usr/share/dotnet /etc/apt/sources.list.d/* /var/cache/apt/archives /usr/local/share/boost /usr/local/go* /usr/local/lib/android /opt/ghc sudo swapoff /swapfile sudo rm -f /swapfile docker rmi "$(docker images -q)" sudo -E apt-get -q purge azure-cli zulu* hhvm llvm* firefox google* dotnet* powershell openjdk* mysql*
多删除了一些文件,你可以照此修改。
dev分支我一直没来得及合并到master,因为变动比较大,README一直没时间写完整
感觉你的缺失有点复杂了点,我也是读了好久大概明白思路之后,然后尝试精简一下,搞了好久,到现在还没成功
主要是现在dev分支比以前精简了很多,取消了各种job,只保留一个。docker image的构建上也能得到更小的image文件,省下一部分layer。它也会定期squash整个image以便压缩空间。这些导致原本写好的README不太适用,暂时没时间编写新的。
你的确实是达到了6小时上限,仅仅编译就花费了5小时时间,上传的docker image可能达到了30G。能看一下你的config.diff长什么样吗?超时以及space问题可能没有什么一劳永逸的办法,只能不断挤压
主要是现在dev分支比以前精简了很多,取消了各种job,只保留一个。docker image的构建上也能得到更小的image文件,省下一部分layer。它也会定期squash整个image以便压缩空间。这些导致原本写好的README不太适用,暂时没时间编写新的。
你的确实是达到了6小时上限,仅仅编译就花费了5小时时间,上传的docker image可能达到了30G。能看一下你的config.diff长什么样吗?超时以及space问题可能没有什么一劳永逸的办法,只能不断挤压
我的config是本地make menuconfig 之后生成的,确保该分支没有问题之后再上传进行生成firwmare的。 https://github.com/Ryuchen/lede/blob/develop/config.seed
抱歉你的问题暂时没有好的解决办法。我记得travis CI好像是分步骤限制时间的,没有总的时间限制。但是恐怕需要改动不少地方,以后有时间我才能看看怎么加
我2个架构的配置 docker hub 空间不足了。。。
hub空间不足?你是指Runner空间不足吧?
hub空间不足?你是指Runner空间不足吧? 上传builder 报的 。 就是docker hub的限制吧。
发来一下log链接吧
发来一下log链接吧 删了。。 。。
没听说hub限制空间。上传builder阶段做了两件事:
我怀疑还是第一阶段的问题。你编译的package数量多吗
没听说hub限制空间。上传builder阶段做了两件事:
- 把container保存为image。这个过程中空间占用量会接近double(container的原文件和压缩后的image layer,后者可能会小一些。很无奈这样的空间浪费暂时无解,没法一边删除原文件一边创建docker image)
- push到docker hub
我怀疑还是第一阶段的问题。你编译的package数量多吗
非常的多 全部 luci插件 kmod fimware iptables-mod-* 一个机型还没问题 2个就没了
这就很难了。即便一次不出问题,随着次数增加很快也会出问题。建议你别在这里花时间了。
其实用docker的唯一目的只是用docker hub作免费存储,而且下载上传速度在Actions里也挺不错。但是缺点也在docker自身的layer模式自由度太低,空间利用率和效率都不高。
如果有什么速度快、容量足、方便调用而且不违反ToS的存储方式,你也可以推荐下
而且你经常需要update_repo\update_feeds时,layer之间文件重复率会很高,空间增大非常快。这个时候需要频繁触发squash,这是一个很耗时、耗空间的操作。我怀疑最终使用效果还不如直接编译
而且你经常需要update_repo\update_feeds时,layer之间文件重复率会很高,空间增大非常快。这个时候需要频繁触发squash,这是一个很耗时、耗空间的操作。我怀疑最终使用效果还不如直接编译 我直接放弃了 不过你的那个 user/{target} 的结构 patch files custom.sh 大法 我拿去用了
没问题。原本我是在dev里删掉了非docker编译方式。看到你目前遇到的问题,准备再加回来。
另外关于空间问题,我记得travis对cache的支持比较好,说不定可以解决,这样就可以完全抛弃docker了(但这就不知道什么时候才有时间实现了
这就很难了。即便一次不出问题,随着次数增加很快也会出问题。建议你别在这里花时间了。
其实用docker的唯一目的只是用docker hub作免费存储,而且下载上传速度在Actions里也挺不错。但是缺点也在docker自身的layer模式自由度太低,空间利用率和效率都不高。
如果有什么速度快、容量足、方便调用而且不违反ToS的存储方式,你也可以推荐下
我倒是有 google drive 无限。。