Conversation
Summary of ChangesHello @ilopezluna, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant improvement to the release management process for the Docker Model CLI by automating the creation of release notes. It sets up a dedicated GitHub Actions workflow that leverages an AI agent to compile and format changes from merged pull requests, ensuring consistent and comprehensive release documentation with minimal manual effort. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request adds a new agent configuration for docker/model-runner to automate the generation of release notes for the CLI. The agent definition is well-structured with clear instructions for the language model. My review focuses on improving the security and robustness of the agent by suggesting more restrictive permissions and clarifying some of the instructions to ensure predictable behavior. Overall, this is a great addition for automating release management.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues, and left some high level feedback:
- In
trigger-model-cli-release, passing the fullrelease-notes.mdcontent viagh workflow run ... -f changelog="${{ steps.notes.outputs.changelog }}"is likely to break on newlines/quotes and may exceed the argument size; consider using--raw-fieldor a file-based/artefact-based mechanism for the changelog input in the target workflow instead of inlining the entire markdown. - The
cli-release-notes-generator.yamlinstructions embed GitHub-style expressions like${{ inputs.release_tag }}inside a static config file, which won’t be interpolated by Actions; if you intend those values to be dynamic, they should be supplied via the workflow inputs/env tocagent-actionrather than embedded as literal strings.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In `trigger-model-cli-release`, passing the full `release-notes.md` content via `gh workflow run ... -f changelog="${{ steps.notes.outputs.changelog }}"` is likely to break on newlines/quotes and may exceed the argument size; consider using `--raw-field` or a file-based/artefact-based mechanism for the changelog input in the target workflow instead of inlining the entire markdown.
- The `cli-release-notes-generator.yaml` instructions embed GitHub-style expressions like `${{ inputs.release_tag }}` inside a static config file, which won’t be interpolated by Actions; if you intend those values to be dynamic, they should be supplied via the workflow inputs/env to `cagent-action` rather than embedded as literal strings.
## Individual Comments
### Comment 1
<location> `.github/workflows/cli-release.yml:229-233` </location>
<code_context>
+ echo "🚀 Triggering model-cli-release workflow"
+ echo " ref: $RELEASE_TAG"
+ echo " release_tag: v$VERSION"
+ gh workflow run release.yml \
+ --repo docker/model-cli-release \
+ -f ref="$RELEASE_TAG" \
+ -f release_tag="v$VERSION" \
+ -f changelog="${{ steps.notes.outputs.changelog }}"
+ echo "✅ model-cli-release workflow triggered"
+
</code_context>
<issue_to_address>
**issue (bug_risk):** Passing multiline release notes via a single `-f changelog="..."` argument to `gh workflow run` is fragile.
Because `changelog` is multiline and injected directly into a double-quoted shell argument, any quotes, backslashes, or large content in the release notes can break or truncate this `gh workflow run` invocation. Consider a safer approach like writing the changelog to a temp file and using `-f changelog=@file` (where supported), or base64-encoding and decoding in the called workflow. At minimum, escape double quotes and backslashes before writing to `$GITHUB_OUTPUT` or before invoking `gh`.
</issue_to_address>
### Comment 2
<location> `.github/workflows/cli-release.yml:57-58` </location>
<code_context>
+ LATEST_TAG=$(git tag --list 'cmd/cli/v*' --sort=-v:refname | head -1)
+ echo "Latest existing CLI tag: ${LATEST_TAG:-<none>}"
+
+ if [ -n "$EXPLICIT_TAG" ]; then
+ # Validate explicit tag format (accept with or without v prefix)
+ if ! echo "$EXPLICIT_TAG" | grep -qE '^v[0-9]+\.[0-9]+\.[0-9]+$'; then
+ echo "::error::Invalid release tag format: '$EXPLICIT_TAG'. Expected format: v<MAJOR>.<MINOR>.<PATCH> (e.g., v1.2.3)"
</code_context>
<issue_to_address>
**suggestion:** Explicit tag validation comment and implementation are inconsistent about allowing a missing `v` prefix.
The implementation only allows tags starting with `v` (`^v[0-9]+\.[0-9]+\.[0-9]+$`), while the comment claims tags without `v` are also valid. Either update the regex/logic to support both forms (e.g. `^v?[0-9]+\.[0-9]+\.[0-9]+$` and strip an optional `v`), or change the comment and error message to state that the `v` prefix is required.
Suggested implementation:
```
if [ -n "$EXPLICIT_TAG" ]; then
# Validate explicit tag format (accept with or without v prefix)
if ! echo "$EXPLICIT_TAG" | grep -qE '^v?[0-9]+\.[0-9]+\.[0-9]+$'; then
echo "::error::Invalid release tag format: '$EXPLICIT_TAG'. Expected format: <MAJOR>.<MINOR>.<PATCH> or v<MAJOR>.<MINOR>.<PATCH> (e.g., 1.2.3 or v1.2.3)"
```
```
VERSION="${EXPLICIT_TAG#v}"
RELEASE_TAG="cmd/cli/v$VERSION"
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
Can we just do releases for https://github.com/docker/model-runner as a monolith? Keeping it simple, test, release everything as one. |
|
Doubling down on @ericcurtin's comment, WDYT if we also remove the CLI's go.mod? |
ilopezluna
changed the title
|
@ericcurtin @doringeman I have updated the PR to only have one |
|
Mind that we'll also need to update https://github.com/docker/packaging/actions/workflows/release-model.yml, https://github.com/docker/release-repo/actions/workflows/plugin.yml, and even docs. |
See docker/model-runner#682. Signed-off-by: Dorin Geman <dorin.geman@docker.com>
3 participants
This pull request makes significant changes to the CI/CD workflows and Go module structure, primarily simplifying build and release processes and removing the separate CLI module. The most impactful changes are the removal of the
cmd/cliGo module, the deletion of the dedicated CLI build workflow, and enhancements to the release workflow, including new triggers for downstream packaging and improved tagging/version output.Go module and build simplification:
cmd/cli/go.modfile, consolidating dependencies into the root module and eliminating the separate CLI module..github/workflows/cli-build.ymlworkflow, removing the dedicated CLI build process.Makefilelinting commands to only rungolangci-linton the root module, no longer running it separately forcmd/cli..github/workflows/ci.yml) to removego mod tidyand checks for thecmd/climodule and workspace files, reflecting the module consolidation.Release workflow enhancements:
.github/workflows/release.yml, removing references to "model-runner images for CE".release_tagandversion, and using them for downstream steps. [1] [2] [3] [4]Downstream workflow triggers and instructions:
model-cli-releaseworkflow in a private repo and the Docker CE packaging workflow, including instructions for manual release steps in the Docker release repo.versionoutput.