konairius/homelab
10
0
Fork 0
Code Issues 11 Pull Requests 1 Packages Projects Releases 1 Wiki Activity

fix: [alert] FluxKustomizationHealthcheckfailed (flux-system) (#1241) #1243

Closed
issue-fix-bot wants to merge 1 commits from alert-fix/issue-1241 into main
pull from: alert-fix/issue-1241
merge into: :main
Conversation 1 Commits 1 Files Changed 1
+3
issue-fix-bot commented 2026-10-11 10:42:26 +00:00
Member
Copy Link
Copy Source

What this PR does

FluxKustomizationHealthcheckfailed fires for flux-system/gitea-mcp because the gitea-mcp Deployment never starts. The container fails at runc init with exec: "-t": executable file not found in $PATH. The manifest sets only args:. In Kubernetes, args replaces the image's CMD but keeps its ENTRYPOINT, and docker.gitea.com/gitea-mcp-server:1.8.1 evidently has no ENTRYPOINT (its binary is started from CMD). So the first arg, -t, is being executed as the program. This PR adds an explicit command: [/app/gitea-mcp] so the existing args are passed to the binary again.

Changes

  • kubernetes/apps/gitea-mcp/deployment.yaml: added command: - /app/gitea-mcp (plus a one-line comment explaining why) to the gitea-mcp container. The args are unchanged.

Verification

Checked live this run:

  • ./.ci-diag/kubectl -n gitea-mcp get pods -o jsonpath=...lastState: pod gitea-mcp-7c88d4fb-dlt2l, image docker.gitea.com/gitea-mcp-server:1.8.1, exitCode: 128, reason: StartError, exec: "-t": executable file not found in $PATH (finishedAt 2026-10-11T10:39:13Z). This confirms the issue's diagnosis.

Not verified: the binary path /app/gitea-mcp. I had no image-inspection tool here: no crane, skopeo or docker, and registry access was not permitted. The path comes from the upstream gitea-mcp Dockerfile (WORKDIR /app, CMD ["/app/gitea-mcp", "-t", "stdio"]), as the issue also says. Before merging, the reviewer should confirm it with
crane config docker.gitea.com/gitea-mcp-server:1.8.1 | jq '.config.Entrypoint, .config.Cmd'.
If the path is wrong, the pod still fails with the same kind of StartError (naming /app/gitea-mcp instead of -t). That is no worse than the current state.

After Flux reconciles:

  • kubectl -n gitea-mcp get pods: 1/1 Running, with no new restarts.
  • kubectl -n gitea-mcp logs deploy/gitea-mcp --tail=30: the server listens on :8080 and there are no "flag provided but not defined" errors for -oauth, -oauth-public-url or -H.
  • flux get kustomization gitea-mcp: Ready=True, and the alert clears.

Notes

  • Once the binary actually starts, the next possible failures are what the issue lists: whether 1.8.1 serves the /healthz probe path and accepts the oauth flags. I couldn't test either while the container can't start. Check the pod logs and probe events after rollout.
  • The imagepolicy/gitea-mcp "no tags in database" warning the issue mentions is unrelated (per the issue). I did not touch the image tag.

Closes #1241

## What this PR does `FluxKustomizationHealthcheckfailed` fires for `flux-system/gitea-mcp` because the `gitea-mcp` Deployment never starts. The container fails at runc init with `exec: "-t": executable file not found in $PATH`. The manifest sets only `args:`. In Kubernetes, `args` replaces the image's `CMD` but keeps its `ENTRYPOINT`, and `docker.gitea.com/gitea-mcp-server:1.8.1` evidently has no ENTRYPOINT (its binary is started from `CMD`). So the first arg, `-t`, is being executed as the program. This PR adds an explicit `command: [/app/gitea-mcp]` so the existing args are passed to the binary again. ## Changes - `kubernetes/apps/gitea-mcp/deployment.yaml`: added `command: - /app/gitea-mcp` (plus a one-line comment explaining why) to the `gitea-mcp` container. The args are unchanged. ## Verification Checked live this run: - `./.ci-diag/kubectl -n gitea-mcp get pods -o jsonpath=...lastState`: pod `gitea-mcp-7c88d4fb-dlt2l`, image `docker.gitea.com/gitea-mcp-server:1.8.1`, `exitCode: 128`, `reason: StartError`, `exec: "-t": executable file not found in $PATH` (finishedAt 2026-10-11T10:39:13Z). This confirms the issue's diagnosis. **Not verified: the binary path `/app/gitea-mcp`.** I had no image-inspection tool here: no crane, skopeo or docker, and registry access was not permitted. The path comes from the upstream gitea-mcp Dockerfile (`WORKDIR /app`, `CMD ["/app/gitea-mcp", "-t", "stdio"]`), as the issue also says. Before merging, the reviewer should confirm it with `crane config docker.gitea.com/gitea-mcp-server:1.8.1 | jq '.config.Entrypoint, .config.Cmd'`. If the path is wrong, the pod still fails with the same kind of StartError (naming `/app/gitea-mcp` instead of `-t`). That is no worse than the current state. After Flux reconciles: - `kubectl -n gitea-mcp get pods`: 1/1 Running, with no new restarts. - `kubectl -n gitea-mcp logs deploy/gitea-mcp --tail=30`: the server listens on :8080 and there are no "flag provided but not defined" errors for `-oauth`, `-oauth-public-url` or `-H`. - `flux get kustomization gitea-mcp`: Ready=True, and the alert clears. ## Notes - Once the binary actually starts, the next possible failures are what the issue lists: whether 1.8.1 serves the `/healthz` probe path and accepts the oauth flags. I couldn't test either while the container can't start. Check the pod logs and probe events after rollout. - The `imagepolicy/gitea-mcp` "no tags in database" warning the issue mentions is unrelated (per the issue). I did not touch the image tag. Closes #1241
issue-fix-bot added 1 commit 2026-10-11 10:42:27 +00:00
fix: [alert] FluxKustomizationHealthcheckfailed (flux-system) (#1241)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
Details
ci/woodpecker/pr/pr-review Pipeline was successful
Details
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Details
243198cd82
review-bot left a comment
Member
Copy Link
Copy Source

🤖 Automated review — model mistral-large-4-0, commit 243198cd82d6bcfd2c07385d0f02741b0c5061e0.

Automated review by the review-bot: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review.

Summary

PR #1243 adds command: [/app/gitea-mcp] to kubernetes/apps/gitea-mcp/deployment.yaml to fix the exec: "-t": executable file not found StartError (issue #1241). The diagnosis is correct and the fix is the right approach — but the identical fix was already merged to master via PR #1245 (commit 28ed49aa, merge 68b99944, 2026-10-11T11:57Z) for the duplicate issue #1242, which was closed when that PR merged. This PR is stale and superseded; it is mergeable: false and merging it would add nothing while conflicting with newer master changes.

🔴 Blocking

  • The change is already on the base branch — superseded by merged PR #1245. The file at master tip 31693cdd (kubernetes/apps/gitea-mcp/deployment.yaml:27-29) already contains exactly what this PR adds: 
    # Image has no ENTRYPOINT (binary is in CMD), so args alone would replace it.
command:
  - /app/gitea-mcp
    PR #1245's diff is byte-identical to this PR's diff (same hunk, same comment wording). Issue #1242 (same root cause, same pod) was closed at 11:57:24Z when #1245 merged; issue #1241 is the duplicate that stayed open. Merging #1243 is a no-op at best.
  • The head branch is behind master and would conflict with / revert a newer fix. The head still has -H http://gitea.gitea.svc.cluster.local:3000 (head deployment.yaml:40), while master has -H https://gitea.renner.uno plus an explanatory comment (master deployment.yaml:39-41, from merged PR #1247 / commit efd63b41). The repo sets allow_fast_forward_only_merge: true and the head is not a descendant of master, so the PR cannot merge as-is (mergeable: false); a rebase would conflict on those lines, and a careless resolution would revert the public-URL fix from #1247.

⚪ Unverified

  • Binary path /app/gitea-mcp. The PR author explicitly flags this as unverified (no crane/skopeo/docker available). I cannot inspect the image config from here either. Indirect evidence it is correct: the identical fix merged via #1245 and the CrashLoopBackOff issue #1242 was closed ~1 minute after that merge, suggesting the pod started. I could not confirm live cluster state (pod Running, /healthz serving, oauth flags accepted) from the repository.
  • Whether issue #1241's alert actually cleared after #1245 merged — the issue is still open with no closing comment; only #1242 was closed.

🟡 Suggestions

  • Close PR #1243 as superseded by #1245, and close issue #1241 as a duplicate of #1242 (or add a comment pointing at the merged fix), so the alert-monitor pipeline stops tracking it.
  • If the pipeline re-opens fix PRs for already-fixed alerts, it should check whether the target file already contains the fix before opening a PR — that would have prevented this duplicate.

🟢 Nits

  • The PR body's "Verification" section is honest and well-structured; no issues there.
  • The one-line comment added above command: is slightly redundant with the issue text but harmless and matches the comment style already on master.

Tests

Not applicable in the usual sense: this is a 3-line Kubernetes manifest change in a GitOps repo. The repo's Woodpecker CI (ci-manifests-test, ci-scripts-test, pr-review) passed on the head SHA 243198cd (all three contexts success). No unit tests exist or are expected for a manifest edit; the real validation is the Flux rollout, which already happened via #1245.

Recommendation

Request changes — 2 blocking issue(s): the fix is already merged on master via PR #1245 (superseded), and the stale head conflicts with the newer -H https://gitea.renner.uno fix from PR #1247. Close this PR as superseded rather than merging.

🤖 **Automated review** — model `mistral-large-4-0`, commit `243198cd82d6bcfd2c07385d0f02741b0c5061e0`. > Automated review by the `review-bot`: it approves only when it found nothing red or yellow, and a human still merges. Push new commits to get a fresh review. --- ## Summary PR #1243 adds `command: [/app/gitea-mcp]` to `kubernetes/apps/gitea-mcp/deployment.yaml` to fix the `exec: "-t": executable file not found` StartError (issue #1241). The diagnosis is correct and the fix is the right approach — but the identical fix was already merged to `master` via PR #1245 (commit `28ed49aa`, merge `68b99944`, 2026-10-11T11:57Z) for the duplicate issue #1242, which was closed when that PR merged. This PR is stale and superseded; it is `mergeable: false` and merging it would add nothing while conflicting with newer master changes. ## 🔴 Blocking - **The change is already on the base branch — superseded by merged PR #1245.** The file at master tip `31693cdd` (`kubernetes/apps/gitea-mcp/deployment.yaml:27-29`) already contains exactly what this PR adds: ```yaml # Image has no ENTRYPOINT (binary is in CMD), so args alone would replace it. command: - /app/gitea-mcp ``` PR #1245's diff is byte-identical to this PR's diff (same hunk, same comment wording). Issue #1242 (same root cause, same pod) was closed at 11:57:24Z when #1245 merged; issue #1241 is the duplicate that stayed open. Merging #1243 is a no-op at best. - **The head branch is behind master and would conflict with / revert a newer fix.** The head still has `-H http://gitea.gitea.svc.cluster.local:3000` (head `deployment.yaml:40`), while master has `-H https://gitea.renner.uno` plus an explanatory comment (master `deployment.yaml:39-41`, from merged PR #1247 / commit `efd63b41`). The repo sets `allow_fast_forward_only_merge: true` and the head is not a descendant of master, so the PR cannot merge as-is (`mergeable: false`); a rebase would conflict on those lines, and a careless resolution would revert the public-URL fix from #1247. ## ⚪ Unverified - **Binary path `/app/gitea-mcp`.** The PR author explicitly flags this as unverified (no crane/skopeo/docker available). I cannot inspect the image config from here either. Indirect evidence it is correct: the identical fix merged via #1245 and the CrashLoopBackOff issue #1242 was closed ~1 minute after that merge, suggesting the pod started. I could not confirm live cluster state (pod Running, `/healthz` serving, oauth flags accepted) from the repository. - **Whether issue #1241's alert actually cleared** after #1245 merged — the issue is still open with no closing comment; only #1242 was closed. ## 🟡 Suggestions - Close PR #1243 as superseded by #1245, and close issue #1241 as a duplicate of #1242 (or add a comment pointing at the merged fix), so the alert-monitor pipeline stops tracking it. - If the pipeline re-opens fix PRs for already-fixed alerts, it should check whether the target file already contains the fix before opening a PR — that would have prevented this duplicate. ## 🟢 Nits - The PR body's "Verification" section is honest and well-structured; no issues there. - The one-line comment added above `command:` is slightly redundant with the issue text but harmless and matches the comment style already on master. ## Tests Not applicable in the usual sense: this is a 3-line Kubernetes manifest change in a GitOps repo. The repo's Woodpecker CI (`ci-manifests-test`, `ci-scripts-test`, `pr-review`) passed on the head SHA `243198cd` (all three contexts `success`). No unit tests exist or are expected for a manifest edit; the real validation is the Flux rollout, which already happened via #1245. ## Recommendation Request changes — 2 blocking issue(s): the fix is already merged on master via PR #1245 (superseded), and the stale head conflicts with the newer `-H https://gitea.renner.uno` fix from PR #1247. Close this PR as superseded rather than merging. <!-- pr-review:sha=243198cd82d6bcfd2c07385d0f02741b0c5061e0 -->
k.renner closed this pull request 2026-10-12 03:49:13 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No Reviewers
review-bot
Labels
Clear labels
apollo
Hermes expert: Immich, Audiobookshelf, Libation, Navidrome, Music Assistant
 atlas
Hermes expert: Talos, Flux, network, Authentik, Matrix, monitoring
 clio
Hermes expert: Paperless, wiki, ical-proxy, TRMNL, websites
 daedalus
Hermes expert: Gitea, Woodpecker, Renovate, review-bot, Hermes
 hestia
Hermes expert: Home Assistant, IoT, MQTT, ESPHome, voice
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
alert-monitor-bot claude-bot (Claude Bot) flux hermes-bot issue-fix-bot k.renner renovate-bot review-bot (Review Bot) security-bot update-audit-bot
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: konairius/homelab#1243