[Feature] 能否考虑在release文件中增加发布仅含有luci-app-openclash的编译前tar.gz文件

[devome]

Verify Steps

• [X] Tracker 我已经在 Issue Tracker 中找过我要提出的问题
• [X] Need 当前 OpenClash 并不包含该功能特性或者还不完善
• [X] Framework 这是 OpenClash 应包含的特性, 并非 Clash 特性
• [X] Meaningful 我提交的不是无意义的 催促更新或修复 请求

Describe the Feature

如果采用自编译，不直接安装预编译的ipk文件，有这两种方式：

1. clone整个仓库，再把luci-app-openclash部分弄出来；
2. 下载对应的tag压缩包，或者下载release中的压缩包。

第一种方式在当前的文件结构下，如果完整clone大约需要8G空间，第二种方式因为包含了clash程序文件，大约需要下载160M文件。在网络不那么好的情况下，这个过程有点耗时。所以希望可以在release文件中，除了发布预编译好的ipk文件外，再额外发布一份仅含有luci-app-openclash编译文件的压缩包。

Describe the Solution

希望可以在release文件中，除了发布预编译好的ipk文件外，再额外发布一份只含有luci-app-openclash编译文件的压缩包。

Describe Alternatives

No response

Additional Context

No response

[zzcabc]

为什么不使用clone --depth=1呢

[devome]

为什么不使用clone --depth=1呢

试过了，大约也是160M，和直接下载tag大小相当。 即使既用 --depth=1，又设置core.sparsecheckout true来只clone luci-app-openclash目录，按git的逻辑也是一样的，160M左右。

[XinSSS]

1295

2209

[devome]

1295 #2209

我上面已经说明过了，即使既用 --depth=1，又设置core.sparsecheckout true来只clone luci-app-openclash目录，按git的逻辑也是一样的，160M左右。

而事实上如果只打包release编译相关文件，只要4M左右。

[XinSSS]

我的意思是你的想法挺好, 而不是拿之前的issue告诉你有解决方法之类的...

我也很头疼编译打包的问题, depth=1对我来说只是第一次拉取比较快, 后面git log里又增加许多文件, 实际我操作git pull时又很慢, 期待有比较好的方法

题外话: 我自己也有个问题, 就是openclash编译到固件中的时候, 实际我上传新固件升级, 但其实openclash里面的一些文件并不会真正更新, 只能是m编译...然后m编译的话, 更新几次之后, openclash上传ipk又无法安装了...原因是openclash是m的, 一些依赖比如ruby也变成m了, 实际就是新固件里面也没有ruby了

[XinSSS]

实际上我觉得只在项目里放源码, 核心放到另外的库里, ipk放到release里 这样看上去更合理一些

[devome]

我的意思是你的想法挺好, 而不是拿之前的issue告诉你有解决方法之类的...

我也很头疼编译打包的问题, depth=1对我来说只是第一次拉取比较快, 后面git log里又增加许多文件, 实际我操作git pull时又很慢, 期待有比较好的方法

题外话: 我自己也有个问题, 就是openclash编译到固件中的时候, 实际我上传新固件升级, 但其实openclash里面的一些文件并不会真正更新, 只能是m编译...然后m编译的话, 更新几次之后, openclash上传ipk又无法安装了...原因是openclash是m的, 一些依赖比如ruby也变成m了, 实际就是新固件里面也没有ruby了

你这种情况可能还是直接编译进固件好些吧，依赖项也直接在固件了。不过编译进固件的是luci部分，不管你m安装还是直接集成在固件中，clash核心都是另外下载的，你要想每次新编译固件把clash核心也同步好，你可以试试编译前自动把旧的已安装固件中的/etc/openclash目录用rsync同步到lede/files下并保持目录结构，那么编译好的固件就直接集成好了clash核心，并且连clash的配置文件都保留。

[XinSSS]

我的意思是你的想法挺好, 而不是拿之前的issue告诉你有解决方法之类的... 我也很头疼编译打包的问题, depth=1对我来说只是第一次拉取比较快, 后面git log里又增加许多文件, 实际我操作git pull时又很慢, 期待有比较好的方法 题外话: 我自己也有个问题, 就是openclash编译到固件中的时候, 实际我上传新固件升级, 但其实openclash里面的一些文件并不会真正更新, 只能是m编译...然后m编译的话, 更新几次之后, openclash上传ipk又无法安装了...原因是openclash是m的, 一些依赖比如ruby也变成m了, 实际就是新固件里面也没有ruby了

你这种情况可能还是直接编译进固件好些吧，依赖项也直接在固件了。不过编译进固件的是luci部分，不管你m安装还是直接集成在固件中，clash核心都是另外下载的，你要想每次新编译固件把clash核心也同步好，你可以试试编译前自动把旧的已安装固件中的/etc/openclash目录用rsync同步到lede/files下并保持目录结构，那么编译好的固件就直接集成好了clash核心。

核心到还好说, 点击就能更新... 但是这里的文件挺多的, 也是没有获得更新 比如这里的 https://github.com/vernesong/OpenClash/tree/master/luci-app-openclash/root/etc/openclash/custom

[devome]

核心到还好说, 点击就能更新... 但是这里的文件挺多的, 也是没有获得更新 比如这里的 https://github.com/vernesong/OpenClash/tree/master/luci-app-openclash/root/etc/openclash/custom

那也可以利用rsync的--include-from=XXX.txt选择性同步：

+ etc
+ etc/openclash
+ etc/openclash/core
+ etc/openclash/core/**
+ etc/openclash/config.yml
...

只要你写好rsync清单就行。其他在luci编译时更新自然就更新进luci了。

[XinSSS]

核心到还好说, 点击就能更新... 但是这里的文件挺多的, 也是没有获得更新 比如这里的 https://github.com/vernesong/OpenClash/tree/master/luci-app-openclash/root/etc/openclash/custom

那也可以利用rsync的--include-from=XXX.txt选择性同步：

+ etc
+ etc/openclash
+ etc/openclash/core
+ etc/openclash/core/**
+ etc/openclash/config.yml
...

只要你写好rsync清单就行。

好的, 谢谢, 我试试看

[zzcabc]

设置core.sparsecheckout true来只clone luci-app-openclash目录，按git的逻辑也是一样的，160M左右。

自己fork项目，然后用GitHub action 打包

[devome]

设置core.sparsecheckout true来只clone luci-app-openclash目录，按git的逻辑也是一样的，160M左右。

自己fork项目，然后用GitHub action 打包

也不是不行，打包也不用fork。但我也不完全是为了自己而提此issue的。

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days