Skip to content

ci(kai-ci): always build from the newest tags, and fix the SIGPIPE #92

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.

Sign up for GitHub

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

Merged
fatihacet merged 1 commit into from
Sep 8, 2026
Merged

ci(kai-ci): always build from the newest tags, and fix the SIGPIPE #92

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 29 additions & 39 deletions .github/workflows/build-kai-ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,28 +36,12 @@ name: build-kai-ci
on:
workflow_dispatch:
inputs:
kai_cli_ref:
description: 'kai-cli ref for `kai` — blank = newest released tag'
required: false
default: ''
kai_tui_ref:
description: 'kai-tui ref for `kit` — blank = newest released tag'
required: false
default: ''
kai_engine_ref:
description: 'kai-engine ref — blank = newest released tag'
required: false
default: ''
kai_core_ref:
description: 'kai-core ref — blank = newest released tag'
required: false
default: ''
pin:
description: 'Open a kai-server PR pinning the new digest'
required: true
type: choice
default: none
options: [none, agent, review, both]
default: both

@greptile-apps greptile-apps Bot Sep 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Default produces malformed PR wording

With both as the default, the pin job interpolates that value into text such as pin the both image, making the automatically generated kai-server pull request confusing.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: .github/workflows/build-kai-ci.yml
Line: 43

Comment:
**Default produces malformed PR wording**

With `both` as the default, the pin job interpolates that value into text such as `pin the both image`, making the automatically generated kai-server pull request confusing.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Claude Code Fix in Codex

options: [both, agent, review, none]

concurrency:
group: build-kai-ci
Expand Down Expand Up @@ -97,11 +81,13 @@ jobs:
owner: kaicontext
repositories: kai-cli,kai-tui,kai-engine,kai-core

# Blank inputs resolve to each repo's newest released tag. Typing "main"
# into four boxes was the common case and the wrong default: a pin is
# described by version ("kai-cli v0.35.65 on kai-engine v0.6.55"), so the
# build should default to versions too, and a branch tip is not a thing
# anyone can point at later.
# ALWAYS the newest released tag of each repo — there is nothing to type.
# A pin is described by version ("kai-cli v0.35.65 on kai-engine v0.6.55"),
# so the build works in versions too, and a branch tip is not something
# anyone can point at afterwards, which is the whole objection this
# workflow exists to answer. Building from a branch is still possible
# locally with deploy/kai-ci/build.sh; it just is not what production
# images are made from.
#
# Newest SEMVER TAG, not GitHub's "latest release": those disagree here.
# kai-engine's newest tag is v0.6.58 while its releases/latest still reads
Expand All @@ -111,28 +97,32 @@ jobs:
id: resolve
env:
TOKEN: ${{ steps.token.outputs.token }}
# What the operator typed — blank for the common case.
KAI_CLI_REF: ${{ inputs.kai_cli_ref }}
KAI_TUI_REF: ${{ inputs.kai_tui_ref }}
KAI_ENGINE_REF: ${{ inputs.kai_engine_ref }}
KAI_CORE_REF: ${{ inputs.kai_core_ref }}
run: |
set -euo pipefail
# No pipe, deliberately. `git ls-remote | head -1` makes head close the
# pipe while git is still writing, git takes SIGPIPE, and under
# `set -o pipefail` the whole step dies with exit 141 — which is how
# the first run of this workflow failed. It is a RACE, not a
# certainty: the same command passed locally because that tag list was
# small enough for git to finish first. Reading the output into a
# variable and slicing the first line in bash removes the race rather
# than making it rarer.
latest_tag() {
git ls-remote --tags --refs --sort=-v:refname \
"https://x-access-token:${TOKEN}@github.com/kaicontext/$1" 'v*' \
| head -1 | sed 's#.*refs/tags/##'
local out first
out="$(git ls-remote --tags --refs --sort=-v:refname \
"https://x-access-token:${TOKEN}@github.com/kaicontext/$1" 'v*')"
[ -n "$out" ] || return 1
first="${out%%$'\n'*}"
printf '%s' "${first##*refs/tags/}"
}
for m in kai-cli kai-tui kai-engine kai-core; do
var="$(echo "$m" | tr 'a-z-' 'A-Z_')_REF"
want="${!var}"
if [ -z "$want" ]; then
want="$(latest_tag "$m")"
[ -n "$want" ] || { echo "no v* tag found for $m — pass a ref explicitly"; exit 1; }
echo "$m: no ref given, using newest tag $want"
else
echo "$m: using the ref you gave, $want"
# `if !` rather than a bare assignment: under `set -e` a failing
# command substitution kills the step with no explanation, and the
# message below never prints.
if ! want="$(latest_tag "$m")" || [ -z "$want" ]; then
echo "no v* tag found for $m — cannot build a versioned image"; exit 1
fi
echo "$m: $want"
echo "$(echo "$m" | tr 'a-z-' 'a-z_')_ref=$want" >> "$GITHUB_OUTPUT"
done

Expand Down