最新代码出来的固件反而变得更旧了。。。 about openwrt-ci HOT 9 CLOSED

12月5日更新:

无论是谁, 如果你在2019年12月4日 04:58 ~ 17:03 (GMT+8) 期间在你的库里首次部署了merge-upstream.yml, 下面的信息对你来说非常重要. (非指定时间段内不受影响)

昨天我review了代码, 发现这个现象其实是CI的BUG. 不幸的是, 这个BUG的影响是灾难性的.

我已经在昨天修复了这个BUG: 8530f58 , 现在已经可以正常使用了.

为什么说影响是是灾难性的呢? 因为github官方的checkout克隆的深度默认是1, 即表层克隆, 这会导致git在merge时不能有效读取到祖先信息, 而我为了CI稳定性, 故意设置成了忽略文件历史, 这会导致合并后文件并不会跟随上游改变.

十分抱歉, 这会导致因为远程服务器的commit log被污染而导致不能后续不能正确合并上游提交. 下面是补救措施.

如果你在你的lege库除了CI脚本外没有做任何更改, 或只做了很少的修改(比如添加一些插件):

1. 备份你的workflows和你添加的插件
2. 删除你的lede库
3. 重新部署你的workflow (注意把merge-upstream.yml修改为最新版本) , 和你的修改.

(危险!!)如果你不是上条所属的情况, 下面我假设你有一定的git知识并知道下面每一步操作的含义:

1. 在commits页面里找到merge-upstream.yml产生的第一次合并操作, 并复制commit hash
2. 把你的库clone到本地
3. 备份下你在merge-upstream.yml产生的第一次合并操作后手动进行的修改
4. 进入你的本地库, 执行:
   git reset --hard <你记下的commit hash>
git push origin <merge-upstream.yml所在的分支名> -f
5. 按要求完成身份验证
6. 重新提交你备份的更改

对于 @adaaaaaa 来说, 采取第一条措施即可.

再次因为这个BUG道歉. 作为补偿, 我愿意为问题的提出者 @adaaaaaa 定制一个云编译CI.

@adaaaaaa , 你可以在下面提交你所需的定制配置.

from openwrt-ci.

我愿意为问题的提出者 @adaaaaaa 定制一个云编译CI.

可以换成教我怎么在docker里装个openwrt固件吗？L大，源码的都行。。。😂😂🤪

from openwrt-ci.

好像docker镜像仓库里面并没有L大的镜像。。。

from openwrt-ci.

官方文档:
https://openwrt.org/start?id=zh/docs/guide-user/virtualization/docker_openwrt_image

from openwrt-ci.

官方文档

在openwrt的docker里运行linux好，还是反过来好？？😂😂😂

from openwrt-ci.

https://www.mlapp.cn/376.html这里提到：
由于容器内系统内核共享宿主机内核，所以在 Luci 面板的 “内核版本”项与宿主机内核版本一致；
linux主机的内核升级会导致op崩溃吗？或者变得不好使？反过来呢？

from openwrt-ci.

在openwrt的docker里运行linux好，还是反过来好？？😂😂😂

反过来. 不光如此, 我甚至严重怀疑在docker中运行op的意义所在.

https://www.mlapp.cn/376.html这里提到：
由于容器内系统内核共享宿主机内核，所以在 Luci 面板的 “内核版本”项与宿主机内核版本一致；
linux主机的内核升级会导致op崩溃吗？或者变得不好使？反过来呢？

可能会. 可能会. 不会.

from openwrt-ci.

在docker里装op能实现所有的功能吗？为什么你觉得docker中运行op意义不大呢？不是性能损失更少吗？

from openwrt-ci.

简单告诉你, 意义不大.

from openwrt-ci.