镜像定期构建申请

wojiushixiaobai commented 8 months ago

部分镜像由于更新很频繁，是否可以启动计划触发构建？

一些无架构问题的镜像，如 python，建议每日自动监控上游版本更新，然后自动触发构建。

需要定制一个标准化自动构建的流程，减少人工介入。

比如 Minio，基本每周都会有更新，可以通过脚本检测版本更新。例：

# github.com/minio/minio
OWNER_NAME=minio
REPO_NAME=minio

# cr.loongnix.cn/repository/minio/minio
CR_OWNER=minio
CR_REPO=minio

function get_app_version() {
  curl -s "https://api.github.com/repos/${OWNER_NAME}/${REPO_NAME}/releases/latest" |
    grep "tag_name" | head -n 1 | awk -F ":" '{print $2}' |
    sed 's/\"//g;s/,//g;s/ //g'
}
function check_app_build() {
  APP_VERSION=$1
  if curl -s "https://cr.loongnix.cn/api/v1/repository/${CR_OWNER}/${CR_REPO}/tag/?limit=100" | grep "${APP_VERSION}"; then 
    echo "Yes"
  fi
}

APP_VERSION=$(get_app_version)
CHECK_BUILD=$(check_app_build)

if [ -n "${RUN_BUILD}" ]; then
  echo "[Info]: 镜像存在，跳过."
  exit 0
fi

## 触发构建逻辑
# 
# make -C ${CR_OWNER}/${CR_REPO} APP_VERSION=${APP_VERSION} ....
....

znley commented 7 months ago

@wojiushixiaobai 我们在考虑进行这个工作，重点包括 kubernetes 和 library 下比较标准的镜像。您有什么初步的项目规划吗？

wojiushixiaobai commented 7 months ago

@znley 目前没什么规划，需要定期构建的原因其实是修复一些安全问题。

一些基础设施应用如果 Dockerfile 本身方便维护或者与上游无冲突，这部分应用是否可以考虑自动化构建构建上传。

[ ] 每日构建触发流程。
[ ] 测试用例（简单的功能验证）。
[ ] 构建通知。

因为当前 cr.loongnix.cn 不对外开放注册，而且旧世界还要维护一段比较长的时间，所以提了这样一个申请，看看是否有现成的流程可以接入。

znley commented 7 months ago

@wojiushixiaobai 我们在考虑整个框架，因为不可能对每一个项目单独开仓库（github repo），需要把这些项目集中管理为一个仓库，要对项目的组织形式和通用框架做一个验证。

wojiushixiaobai commented 4 months ago

@znley 您好管理员，请问有什么新进展吗？我看到 actions 里面已经新增了一个 crontab 任务，但是这个并不能满足所有项目的需求。

按之前的思路，每个项目需要自己维护一个 renew 的脚本（由此项目管理员维护，比如 library/python/renovate-version.sh）这个脚本维护 Python 这个项目的版本检测和更新方式，如：

# 通过 renovate-version.sh --check <version> 检测 v3.11 的最新版本，并返回一个 v3.11 的最新版本比如 v3.11.9
bash library/python/renovate-version.sh --check v3.11

# 然后比对现在的项目是否存在这个版本的相关代码，如果没有则
# 通过 renovate-version.sh --create <version> 创建 v3.11.9 版本的相关文件

# 最后上传

注：待检测的版本号（如：v3.11）可以写在 renovate-version.sh 的同名目录下文件中（如 check_version）不直接从 Makefile 或 Dockerfile 取版本是为了防止一些复杂的项目特定版本可能需要比较大的修改。

cat check_version

v3.10
v3.11
v3.12

完整的大致逻辑如下：

检测项目是否包含特定自动化处理版本的相关文件
获取需要检测的项目和检测的版本
git 检出并切换到特检测项目分支（如：renovate_python_version_v3.11）
在特定分支（如：renovate_python_version_v3.11）执行脚本进行处理版本变更
git 检测是否有文件变更，如果有变更则提交此分支并发起 PR 请求
git 清理分支，重新切换回主线，继续下一个项目直到所有项目检测完成

这样后，可能项目的结构也可以调整下：

比如 library/python/v3.7.10 可以优化成 library/python/v3.7 只维护最新版本

以上，大多只是我个人的一些想法，仅供参考。

znley commented 4 months ago

@wojiushixiaobai 二进制的版本构建在 https://github.com/Loongson-Cloud-Community/cloud-releases/tree/multiple-version 完成了一部分，只需要触发即可，镜像还没考虑，但猜测可以按照这样的方式进行

wojiushixiaobai commented 4 months ago

@znley 好的，那我先用 Actions 简单实现一个，把改动比较小的代码自动化处理一下。暂时存储到下面仓库，等后面主仓库支持后移除。

https://github.com/wojiushixiaobai/Loongson-dockerfiles-renovate

Loongson-Cloud-Community / dockerfiles

镜像定期构建申请 #161