ci: build test image on master pushes #3120
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
你好 - 我已审阅了你的更改 - 以下是一些反馈：
- 版本解析的组合 if/else 逻辑相当复杂——考虑将 master‐push 和 tag‐release 构建拆分为单独的工作流或作业，以简化维护。
- 依赖 github.ref_type/ref_name 可能很脆弱——解析 github.ref (refs/heads/… vs refs/tags/…) 在不同的 GitHub 事件类型中更健壮。
- 为每个 master 构建使用静态“test”标签会覆盖之前的镜像；考虑附加一个简短的提交 SHA 或构建号，以便更好地追溯测试镜像。
给 AI 代理的提示
请处理此代码审查中的评论：
## 总体评论
- 版本解析的组合 if/else 逻辑相当复杂——考虑将 master‐push 和 tag‐release 构建拆分为单独的工作流或作业，以简化维护。
- 依赖 github.ref_type/ref_name 可能很脆弱——解析 github.ref (refs/heads/… vs refs/tags/…) 在不同的 GitHub 事件类型中更健壮。
- 为每个 master 构建使用静态“test”标签会覆盖之前的镜像；考虑附加一个简短的提交 SHA 或构建号，以便更好地追溯测试镜像。帮助我更有用！请点击每个评论上的 👍 或 👎，我将利用这些反馈来改进你的审查。
Original comment in English
Hey there - I've reviewed your changes - here's some feedback:
- The combined if/else logic for version resolution is quite complex—consider splitting master‐push and tag‐release builds into separate workflows or jobs to simplify maintenance.
- Relying on github.ref_type/ref_name can be fragile—parsing github.ref (refs/heads/… vs refs/tags/…) is more robust across different GitHub event types.
- Using a static “test” tag for every master build overwrites previous images; consider appending a short commit SHA or build number for better traceability of test images.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The combined if/else logic for version resolution is quite complex—consider splitting master‐push and tag‐release builds into separate workflows or jobs to simplify maintenance.
- Relying on github.ref_type/ref_name can be fragile—parsing github.ref (refs/heads/… vs refs/tags/…) is more robust across different GitHub event types.
- Using a static “test” tag for every master build overwrites previous images; consider appending a short commit SHA or build number for better traceability of test images.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
没事了，刚刚我没注意到 |
是的，标签和提交哈希都有，但是只用哈希的话，compose文件没办法引用，必须有个标签才行 |
你那边测试情况如何 |
之前没试，试了一下发现问题出在奇怪的地方，我按默认默认配置 我改成PAT |
…cker-hub-failure Make GHCR publishing optional in Docker workflow
|
@LIghtJUNction 基本搞定了，主要原因感觉是仓库owner的问题，在这边应该问题不大，后边几个关于owner的修改带不带都行，另外尝试了多次，提交的log看起来也比较难受，好在功能是正常的 =============================
- web端功能正常：
|
辛苦你了 |
|
@Soulter 这个可以合吗 |
|
感觉没问题了 把 DOCKER_HUB_TOKEN 改回了 DOCKER_HUB_PASSWORD，和现在的一致 |
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the Docker CI/CD workflow to support separate test and release image builds, with improved handling of pre-release versions and multi-registry support.
Key Changes:
- Split the workflow into two jobs:
build-test-image(for master branch commits) andbuild-release-image(for tagged releases) - Enhanced registry support with conditional GHCR (GitHub Container Registry) integration
- Improved metadata handling and tag generation for both test and release images
Reviewed Changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| README.md | Adds trailing whitespace to section header (cosmetic) |
| .github/workflows/docker-image.yml | Splits workflow into test and release jobs with improved tagging, conditional GHCR support, and refactored metadata handling |
| ${{ steps.release-meta.outputs.is_prerelease == 'false' && env.HAS_GHCR_TOKEN == 'true' && format('ghcr.io/{0}/astrbot:latest', env.GHCR_OWNER) || '' }} | ||
| ${{ format('{0}/astrbot:{1}', env.DOCKER_HUB_USERNAME, steps.release-meta.outputs.version) }} | ||
| ${{ env.HAS_GHCR_TOKEN == 'true' && format('ghcr.io/{0}/astrbot:{1}', env.GHCR_OWNER, steps.release-meta.outputs.version) || '' }} |
There was a problem hiding this comment.
Empty string tags ('') will cause the Docker build to fail. When HAS_GHCR_TOKEN is false, these expressions produce empty tags which Docker cannot process. Consider filtering these tags conditionally in a separate step or using multi-line YAML syntax to conditionally include the lines.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
3 participants
fixes #3119
Motivation / 动机
Modifications / 改动点
/.github/workflows/docker-image.yml：master分支 push 的触发。Resolve build version步骤，区分标签、手动触发与分支构建，主分支固定输出test版本号。docker/build-push-action标签逻辑：标签构建继续推送latest，主分支推送astrbot:test（同步到 DockerHub 与 GHCR）。Verification Steps / 验证步骤
master（或在 fork/测试仓库的同名分支模拟）。masterpush 被触发并成功完成。<DOCKER_HUB_USERNAME>/astrbot:test是否更新为最新镜像（可通过标签时间或docker pull查看）。v4.3.4），再次确认工作流推送了latest与版本号标签，确保标签发布逻辑未回归。Screenshots or Test Results / 运行截图或测试结果
Compatibility & Breaking Changes / 兼容性与破坏性变更
Checklist / 检查清单
requirements.txt和pyproject.toml文件相应位置。/ I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations inrequirements.txtandpyproject.toml.Sourcery 总结
在
master分支推送时触发 Docker 镜像构建，添加一个版本解析步骤以区分标签、分支和手动触发的构建，并更新build-push-action的标签逻辑，为master分支生成'test'镜像并正确管理'latest'和版本标签。CI:
master分支推送时触发工作流，并添加一个版本解析步骤，以区分标签、分支和手动触发的构建（为master分支分配'test'）。docker/build-push-action的标签以使用解析后的版本，为master构建推送'astrbot:test'，并为稳定版本提供条件性的'latest'和发布标签。Original summary in English
Summary by Sourcery
Trigger Docker image builds on master branch pushes, add a version resolution step to differentiate tag, branch, and manual dispatch builds, and update the build-push-action tagging logic to generate 'test' images for master and manage 'latest' and version tags correctly.
CI: