no space left

[Ryuchen]

[tete1030]

第一次遇见这种，你用的是master还是dev分支？重试一次还会出现这样的错误吗？错误是一开始编译就出现还是编译过程中出现的？

[Ryuchen]

我是在编译过程中，用的master分支，我编译的X86固件本身就比较大，不知道是不是插件太多的缘故，我本地编译的话，需要23G的空间，用的是master分支

[tete1030]

编译到哪一步出的问题？

[Ryuchen]

compile 那个步骤出现的问题

[tete1030]

这是我在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一直没时间写完整

[Ryuchen]

嗯，我昨天查看了你的源码，然后把这段加上了，但是还是出现了问题，不过这次是在push 到docker hub时出现问题了
麻烦您看下我的actions

https://github.com/Ryuchen/lede/runs/492193751?check_suite_focus=true

[Ryuchen]

查了一下，好像是整个workflow的时间超过了6个小时

[Ryuchen]

这是我在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一直没时间写完整

感觉你的缺失有点复杂了点，我也是读了好久大概明白思路之后，然后尝试精简一下，搞了好久，到现在还没成功

[tete1030]

主要是现在dev分支比以前精简了很多，取消了各种job，只保留一个。docker image的构建上也能得到更小的image文件，省下一部分layer。它也会定期squash整个image以便压缩空间。这些导致原本写好的README不太适用，暂时没时间编写新的。

你的确实是达到了6小时上限，仅仅编译就花费了5小时时间，上传的docker image可能达到了30G。能看一下你的config.diff长什么样吗？超时以及space问题可能没有什么一劳永逸的办法，只能不断挤压

[Ryuchen]

主要是现在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

[tete1030]

抱歉你的问题暂时没有好的解决办法。我记得travis CI好像是分步骤限制时间的，没有总的时间限制。但是恐怕需要改动不少地方，以后有时间我才能看看怎么加

[ghost]

我2个架构的配置 docker hub 空间不足了。。。

[tete1030]

hub空间不足？你是指Runner空间不足吧？

[ghost]

hub空间不足？你是指Runner空间不足吧？
上传builder 报的 。 就是docker hub的限制吧。

[tete1030]

发来一下log链接吧

[ghost]

发来一下log链接吧
删了。。 。。

[tete1030]

没听说hub限制空间。上传builder阶段做了两件事：

1. 把container保存为image。这个过程中空间占用量会接近double（container的原文件和压缩后的image layer，后者可能会小一些。很无奈这样的空间浪费暂时无解，没法一边删除原文件一边创建docker image）
2. push到docker hub

我怀疑还是第一阶段的问题。你编译的package数量多吗

[ghost]

没听说hub限制空间。上传builder阶段做了两件事：

1. 把container保存为image。这个过程中空间占用量会接近double（container的原文件和压缩后的image layer，后者可能会小一些。很无奈这样的空间浪费暂时无解，没法一边删除原文件一边创建docker image）
2. push到docker hub

我怀疑还是第一阶段的问题。你编译的package数量多吗

非常的多 全部 luci插件 kmod fimware iptables-mod-*
一个机型还没问题 2个就没了

[tete1030]

这就很难了。即便一次不出问题，随着次数增加很快也会出问题。建议你别在这里花时间了。

其实用docker的唯一目的只是用docker hub作免费存储，而且下载上传速度在Actions里也挺不错。但是缺点也在docker自身的layer模式自由度太低，空间利用率和效率都不高。

如果有什么速度快、容量足、方便调用而且不违反ToS的存储方式，你也可以推荐下

[tete1030]

而且你经常需要update_repo\update_feeds时，layer之间文件重复率会很高，空间增大非常快。这个时候需要频繁触发squash，这是一个很耗时、耗空间的操作。我怀疑最终使用效果还不如直接编译

[ghost]

而且你经常需要update_repo\update_feeds时，layer之间文件重复率会很高，空间增大非常快。这个时候需要频繁触发squash，这是一个很耗时、耗空间的操作。我怀疑最终使用效果还不如直接编译
我直接放弃了 不过你的那个 user/{target} 的结构 patch files custom.sh 大法 我拿去用了

[tete1030]

没问题。原本我是在dev里删掉了非docker编译方式。看到你目前遇到的问题，准备再加回来。

另外关于空间问题，我记得travis对cache的支持比较好，说不定可以解决，这样就可以完全抛弃docker了（但这就不知道什么时候才有时间实现了

[ghost]

这就很难了。即便一次不出问题，随着次数增加很快也会出问题。建议你别在这里花时间了。

其实用docker的唯一目的只是用docker hub作免费存储，而且下载上传速度在Actions里也挺不错。但是缺点也在docker自身的layer模式自由度太低，空间利用率和效率都不高。

如果有什么速度快、容量足、方便调用而且不违反ToS的存储方式，你也可以推荐下

我倒是有 google drive 无限。。

[snowyu]

1. Only make container for Openwrt Image Builder, Use the GitHub Packages(Container) Registry: https://docs.github.com/cn/packages/working-with-a-github-packages-registry/working-with-the-docker-registry
2. Or mount image file to compile and save the image file to Github Release assets as cache. klever1988/nanopi-openwrt/.github/workflows/lo-test.yml