-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Github actions 打包支持 #149
Comments
1. 安全性的话,其实也有办法,比如 userns + bind mount 或者 syscall filter 限制一下就好了。编译机上了 cgroups v2,所以 docker 已经跑不动了。 2. 不要搞特殊哇。新建个 runner 字段多好。 6. 那就先把 #145 给解决了。 8. 为什么要用 js 啊,那些 pre/post_build,不能调 Python 的吗? |
2. 都可以😂 8. 如果前置环境配好了可以调用python的lilac
或者就是直接用shell重写pre_build中自定义的部分,其他封装
我比较倾向后者,配置环境每个run都会做,少重复一点是一点 |
我决定优先推进一下这个了。。。 我想了一下重新造一遍lilac的轮子还是不太好。。。 总之我就做了一个完全兼容现有lilac.py的workflow
下一步只要在single_main那里
我觉得就目标达成了 问题与讨论
|
这个 GitHub Actions 的免费配额和限制文档在哪里来着? kill_children 除了超时处理外,也用于大日志的处理,所以还是需要的(除非你想等着有问题的构建把所有可用空间写完然后等超时)。 你是想让每个包独立跑,还是你在服务器上跑一个 lilac 实例来调度? 复用 lilac 的代码吧,那么多 api 函数你重新实现起来也挺费事的。 我想比较好的方案是,只把更新检查和构建过程交给 github actions,剩下的事务还是由 lilac 处理。single_main 是给本地跑来测试用的,我们可以再为 github actions 搞一个 github_main,在其中做依赖包下载之类的事情。 |
应该是docker hub,这里有个测试第三方container的例子
对公有repo没有限额,只对私有有限额。
本地服务器上跑一个 lilac 实例来调度,每个包由build.yml派生一个独立的runner打包。runner之间可以并行。
那也不应该是kill_children,直接通过API把这个workflow取消就行
检查更新也可以么?其实nvchecker的话,加个proxy的选项应该就能解决网络问题。。。
那就action_main吧,可以通过sys.argv[1]区分。
我在想要不artifact不在了,说明肯定超过60天了,那也就rebuild一遍得了? |
这个么? 另外我看到你的 initialize.sh 脚本里安装了一些依赖包。这个可能会导致打出来的包隐式地依赖上这些包。是否可能再调用 archbuild 脚本来打包?
所以可以跑需要运行很长时间的任务?
嗯,有 API 那就用 API。
实际上 nvchecker 是最容易搬上 github actions 上的呀。当然你不想搬也可以不搬。
可以是可以。但是这就会导致不必要的依赖包更新呢。虽然可能解决一些问题,但也会引出另一些问题。
|
我觉得是
现在就是调用的archbuild,log里可以看到
时间是6小时。先把简单的包搬上去,之后可能通过自建runner把其他搬上去吧。。。
那可能就不做这个了吧。。。 |
我做了一个带依赖打包的预览了 目前还是只从repo下载,从artifact下载WIP 主要功能:
|
(终于打出了因为网络问题失败好几周的包,老母亲留下了欣慰的泪水) |
试试使用这个处理包下载? https://github.com/archlinuxcn/lilac/blob/gh-actions/lilac2/remote/gh_actions.py 我不知道当前用户有没有 /var/cache/pacman/pkg 的写权限。如果没有,需要换一个目录来放下回来的缓存文件。 另外这个缓存需要手动管理么?还是 github 会自动删掉过多的文件呀? |
可能得等等了,今天打算做一个简单的 action-extra-x86_64-build ,然后把后面跟lilac对接的先都走通。然后就得下周末才有时间了。。。 不过初步看了一下,从repo下载那,我觉得目前的alpm下载相对于download-package-from-artifact.sh的pacman自带下载还有这些问题:
当前的cache使用方式是 每次把cache文件夹由 https://github.com/actions/cache 快照成一个 限制为所有快照文件的容量为5G,超了就会从老的开始删,直到小于 5G 所以最好就是在不超过5G的情况下尽可能多塞东西。。。 据我之前的观察,如果不存repo_depends,剩下的差不多就是5G 如果某个特定包经常要下大repo_depends,可能得开个马甲repo只打这个包,这样就独享一个5G cache |
这些应该都有。不过 gpg 需要设置好。记得把 keyring 包装上应该就好了。我测试的时候,截断文件它会报告校验和错误,所以我不确定它有没有用 gpg……
可以。去把 utils.py 里那个路径改了就行了。 |
我觉得这样不好。。。最好是专门做一个 gpgdir |
啊,pyalpm 没实现 questioncb……指定 gpgdir 倒是没有问题。 |
算了,既然不要缓存的话,暂时用不着回答问题。 |
从artifact下载包还有个冒号的问题 |
On Fri, Jun 12, 2020 at 06:30:34AM -0700, Jingbei Li wrote:
从artifact下载包还有个冒号的问题
就是文件名的`:`我都替换成了`COLON`
否则不让上传。。。
下载后得自己换回来。。。
囧……不过 pacman 应该不会在意那个的。
…--
Best regards,
lilydjwg
|
#!/bin/sh
set -e
export TOKEN=
repo=petronny/arch4edu
package=$(realpath .)
package=$(basename $package)
uuid=$(uuidgen)
curl -sS -X POST https://api.github.com/repos/${repo}/dispatches \
-H "Accept: application/vnd.github.everest-preview+json" \
-H "Authorization: token $TOKEN" \
--data "{\"event_type\": \"$package $uuid\"}"
while true
do
sleep 30
download-file-from-artifact.zsh \
--repo ${repo} \
--file $package.$uuid \
--type file \
--save-path . 2>/dev/null || continue
break
done
mv $package.$uuid workflow_id
workflow_id=$(cat workflow_id)
download-file-from-artifact.zsh \
--repo ${repo} \
--workflow $workflow_id \
--file $package.log \
--type file \
--save-path /tmp \
--save-json artifact.json || (echo "Error:\tDownload $package.log failed" && exit 1)
cat /tmp/$package.log
download-file-from-artifact.zsh \
--repo ${repo} \
--workflow $workflow_id \
--file $package.patch \
--type file \
--save-path /tmp || (echo "Error:\tDownload $package.patch failed" && exit 1)
for i in $(git status -s | grep " M" | cut -c 4-)
do
git checkout -- $i
done
for i in $(git status -s | grep "^A" | cut -c 4-)
do
[ $(basename $i) = artifact.json ] && continue
[ $(basename $i) = workflow_id ] && continue
rm $i
done
git add workflow_id artifact.json
git apply /tmp/$package.patch
download-file-from-artifact.zsh \
--repo ${repo} \
--workflow $workflow_id \
--file $package \
--type package \
--save-path . || (echo "Error:\tDownload $package failed" && exit 1)
action_main也好了。整体配套是这样
sys.argv[1]是'action'的时候(action中运行的时候会加这个参数) 没有 问题与讨论1. 现在有4个从artifact下载东西的sh...
这4个应该是要合并成一个函数的,但我shell不太会写argparse...先分成4个了。。。 2. 有关uuid 3. 执行 action-extra-x86_64-build 前,lilac会运行一次pre_build 我有个问题是 或者有更好的解决办法么。。。 |
这就是为什么我要用 Python。
你是要 |
能顺便帮忙pr一个
下周再看[捂脸] |
pacman -Swd 不行么? |
貌似是 pacman -Swdd
我打算zsh试试。。。 |
发现了一个小问题 list all artifacts 这个API得通过翻页才能列出所有的 artifacts 目前这个API在以下几处用到了:
我想了以下解决办法:
但感觉传文件这里文件重复度有点高, |
你才发现啊……翻页我那个分支里已经做了处理了。 你会有很多页么?不多的话应该没太大关系,如果太多就把太旧的删掉? |
应该会有很多吧 一个包传4个文件,假设每天100个包,60天,100个每页,总计240页。 |
呃,那看来得用 v4 了…… |
不过可以限制到只找2天内的。8页吧。 虽然我觉得还是有点多 100个包都找8页也800次请求了,并且可能会比100个包多。。。 |
我想了一下其实貌似可以不冲突? 感觉可以 while true
do
git push && break || git pull --rebase
done 有个问题,这个repo可不可以和存lilac.py的repo是一个?就是和lilac.py存一块 就是多存一个artifacts.json和(可选)workflow_id |
4合1了。https://github.com/petronny/action-tools/blob/master/download-file-from-artifact.zsh |
现在 arch4edu 的 ncurses5-compat-libs 和 vim-youcompleteme-git 就是 https://github.com/petronny/arch4edu/actions/runs/134418854 https://github.com/petronny/arch4edu/actions/runs/134422382 后续对接也正常。
我目前就是把这俩都存了。我想了一下还是存repo里最好。
(我们只能通过不同repo来调用不同的runner) 目前我是打算接着改造 action_tools,现在存了 |
这里有个需求。。。就是能不能把lilac的最后一push改成每个都push |
On Tue, Jun 23, 2020 at 12:35:21AM -0700, Jingbei Li wrote:
> 就是多存一个artifacts.json和(可选)workflow_id
这里有个需求。。。就是能不能把lilac的最后一push改成每个都push
或者至少通过action打包的成功后push一下,否则这俩文件没法同步。。。
不能。月初的时候尝试过,结果出现了一些问题。
最主要的是,push 前必须 pull 任何新增的修改,造成 lilac 无法得到一致的仓
库内容。
有一种办法是 pull 和 push 操作另外放一个分支,当前批次 lilac 并不使用,
结束的时候再合并过来。实现起来挺麻烦。
…--
Best regards,
lilydjwg
|
那。。。实在不行就另开个仓库存吧。。。 也好,这样lilac改动更少了 |
On Tue, Jun 23, 2020 at 01:09:17AM -0700, Jingbei Li wrote:
那。。。实在不行就另开个仓库存吧。。。
也好,这样lilac改动更少了
嗯,这主意不错。专门开个仓库存,保证 push 成功。
…--
Best regards,
lilydjwg
|
我把 |
有一个需求。。。 我打算在lilac本地调用时,把pre_build post_build都跳过。 然而,在 https://github.com/archlinuxcn/lilac/blob/master/lilac#L128 另外这里我觉得有点奇怪,直接从PKGBUILD中就可以读了啊,为什么要用 |
都跳过了,那你还用 lilac 干嘛呢。 用 _G 是因为,已经读到了,干嘛再读一次呢…… |
得用啊,不是计划的lilac来定哪些要打包及打包顺序调度,签名等等。。。 那。。。我还是判断一下吧。。。 |
哦那个。计划是打包部分在 Actions 上运行,lilac 这边自然就不执行相应的代码了呀。 |
archlinuxcn/repo#1575
FAQ:
必要性何在
我觉得带有run_cmd的lilac.*其实都是不安全的,万一来一个
rm -rf ~
虽说不会搞炸系统但是也很恶心的,所以扔个docker里跑可能也挺好的剩下的就是透明度啥的
和现有的lilac是什么关系
我打算把这个作为一个特殊的build_prefix交给lilac,即整体还是由lilac决定打哪些包和时序上的依赖关系
然后每个pkgbase都做一个专门的workflow,lilac通过发送一个内容为对应pkgbase的POST请求触发workflow
结束时一个artifact到这个workflow run,然后lilac下载这个artifact就可以和原来的lilac兼容
可否使用devtools
可以
依赖关系如何解决
首先前置依赖的包的artifact是60天有效。
然后对于一个有依赖的包,先查找依赖包的artifact还在不在,在的话直接下载这个;
如果artifact不在了,说明肯定超过60天了,mirror里肯定有,从合适的mirror下载即可。
缓存如何解决
github actions有缓存,不过只有5G大小。
建议是做一个叫pacman-cache-x86_64的缓存只用来缓存extra-x86_64-build下载的包。
repo_depends、source等的只能下载了
性能问题如何解决
虽然单个包的确慢,但结合 非阻塞式打包支持 #145 的话,20个包并行打还是很好的。
对于某些特别吃资源的包,可以不用这个,还在本地打包。
后期的话希望lilac也由一个专门的workflow来运行,高性能服务器做一个self-hosted action runner
有无预览
我给无依赖的yay做了一个,可以参考 https://github.com/petronny/arch4edu/blob/master/.github/workflows/yay.yml
一个对应的运行实例在
https://github.com/petronny/arch4edu/actions/runs/113176984
打包结果和log在
https://github.com/petronny/arch4edu/suites/710761537/artifacts/6924885
https://github.com/petronny/arch4edu/suites/710761537/artifacts/6924884
目前还有何问题
我可以做一个python版本的,就是递归读一下yml,然后用github token/mirror下载
但最好是通过js实现并封装
调查了一下可以通过自定义action的做法封装一些固定操作
我写了一个预览版(就是假设actions都封装好了),见最后
应该和原来的lilac.*差不多了
查了一下custom actions分为docker和js版两种。
我们应该是要用js版的,就是在js里调用各种shell命令,下载文件什么的
可以参考 https://github.com/actions/checkout ,
这个就是通过git命令clone一个repo到当前目录,后面的steps可以读。
所以文件IO,命令执行什么的应该都是可行的。
不过有个问题是我js基本不会。。。所以需要帮助了。。。
The text was updated successfully, but these errors were encountered: