guettli/sharedinbox
1
0
Fork 0
Code Issues 21 Pull Requests 6 Actions Packages Projects Releases Wiki Activity

Do dummy commit to check ci.yml #349

New Issue
Closed
opened 2026-06-02 04:27:16 +00:00 by guettli · 1 comment
guettli commented 2026-06-02 04:27:16 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Do dummy commit to check ci.yml

Does it fail fast now?

Fix if not.

Do dummy commit to check ci.yml Does it fail fast now? Fix if not.
guettlibot commented 2026-06-02 04:50:02 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Let me look at the CI configuration and relevant files to understand what needs to be done.Now let me look at the Taskfile to understand the available tasks.Let me check the scripts directory to understand the full picture.Let me check the pre-commit config to understand format checking.Let me check for the Forgejo workflows directory since this is a Codeberg project.The actual CI files are in .forgejo/workflows/. Let me read them.Let me check the Dagger CI module and other relevant workflow files.Now I have a complete picture. The real CI is in .forgejo/workflows/ci.yml which already uses task check-dagger. Let me analyze the fail-fast behavior in ci/main.go.

The issue: in Check(), the backend/integration tests use errgroup.WithContext. When one test fails, the egCtx is cancelled, causing the other test to output "context canceled". The retry_dagger function in Taskfile.yml matches that string and spuriously retries up to 3× (potentially 30+ minutes instead of 10).

The fixes:

  1. Parallelize CheckHygiene + CheckLayers using errgroup.Group
  2. Switch backend+integration from errgroup.WithContext to plain errgroup.Group — prevents "context canceled" from triggering retries
  3. Remove context canceled from the retry condition in check-daggerNow fix the retry condition in Taskfile.yml to remove context canceled:Now let me verify the changes look correct:Good. Let me verify the Taskfile change:Both changes look correct. Now let me create the branch and commit:PR #350 is open at https://codeberg.org/guettli/sharedinbox/pulls/350.

Here's what I found and fixed:

Root cause — two bugs prevented fail-fast behavior:

  1. Hygiene + layers ran sequentially (ci/main.go:Check()). Since both are cheap grep-based checks with no dependency on each other, they now run in parallel via errgroup.Group.

  2. Spurious 3× retries caused by errgroup.WithContext — the backend and integration tests shared a derived context. When one test failed, the context was cancelled, causing the sibling to emit "context canceled" in Dagger's --progress=plain output. The retry_dagger function in Taskfile.yml treated that string as a transient network error and re-ran the full pipeline up to 3 times. A genuine test failure could take 30+ minutes to report instead of ~10.

Fixes:

  • ci/main.go: Parallelized hygiene+layers checks; switched backend+integration from errgroup.WithContext to errgroup.Group (no shared cancel context, so no spurious "context canceled" in output)
  • Taskfile.yml: Removed context canceled from the retry_dagger grep pattern — the remaining patterns still cover genuine network/engine transients
Let me look at the CI configuration and relevant files to understand what needs to be done.Now let me look at the Taskfile to understand the available tasks.Let me check the scripts directory to understand the full picture.Let me check the pre-commit config to understand format checking.Let me check for the Forgejo workflows directory since this is a Codeberg project.The actual CI files are in `.forgejo/workflows/`. Let me read them.Let me check the Dagger CI module and other relevant workflow files.Now I have a complete picture. The real CI is in `.forgejo/workflows/ci.yml` which already uses `task check-dagger`. Let me analyze the fail-fast behavior in `ci/main.go`. The issue: in `Check()`, the backend/integration tests use `errgroup.WithContext`. When one test fails, the `egCtx` is cancelled, causing the other test to output `"context canceled"`. The `retry_dagger` function in `Taskfile.yml` matches that string and spuriously retries up to 3× (potentially 30+ minutes instead of 10). The fixes: 1. Parallelize `CheckHygiene` + `CheckLayers` using `errgroup.Group` 2. Switch backend+integration from `errgroup.WithContext` to plain `errgroup.Group` — prevents "context canceled" from triggering retries 3. Remove `context canceled` from the retry condition in `check-dagger`Now fix the retry condition in `Taskfile.yml` to remove `context canceled`:Now let me verify the changes look correct:Good. Let me verify the Taskfile change:Both changes look correct. Now let me create the branch and commit:PR #350 is open at https://codeberg.org/guettli/sharedinbox/pulls/350. --- Here's what I found and fixed: **Root cause — two bugs prevented fail-fast behavior:** 1. **Hygiene + layers ran sequentially** (`ci/main.go:Check()`). Since both are cheap grep-based checks with no dependency on each other, they now run in parallel via `errgroup.Group`. 2. **Spurious 3× retries caused by `errgroup.WithContext`** — the backend and integration tests shared a derived context. When one test failed, the context was cancelled, causing the sibling to emit `"context canceled"` in Dagger's `--progress=plain` output. The `retry_dagger` function in `Taskfile.yml` treated that string as a transient network error and re-ran the full pipeline up to 3 times. A genuine test failure could take 30+ minutes to report instead of ~10. **Fixes:** - `ci/main.go`: Parallelized hygiene+layers checks; switched backend+integration from `errgroup.WithContext` to `errgroup.Group` (no shared cancel context, so no spurious `"context canceled"` in output) - `Taskfile.yml`: Removed `context canceled` from the `retry_dagger` grep pattern — the remaining patterns still cover genuine network/engine transients
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
NeedSupervisor
Issue escalated to a human supervisor; agentloop will skip it until cleared.
 State/InProgress
State/Later
State/Planned
automerge
Eligible for automatic merge by CI
 ci-failure
Issue opened by agentloop to track a failing CI workflow; used for deduplication.
 do-not-merge
Plan PR — review only, do not merge.
 loop/code
Add to run the built-in "code" prompt; override at prompts/code.md.
 loop/code-ci-pending
Prompt "code" finished; waiting for the PR's CI to pass before advancing.
 loop/code-done
Prompt "code" finished successfully.
 loop/code-in-process
Agent for the "code" prompt is currently running on this issue.
 loop/merge
Managed by agentloop
 loop/merge-done
Managed by agentloop
 loop/merge-in-process
Managed by agentloop
 loop/plan
Add to run the built-in "plan" prompt; override at prompts/plan.md.
 loop/plan-done
Prompt "plan" finished successfully.
 loop/plan-in-process
Agent for the "plan" prompt is currently running on this issue.
No labels loop/code-done
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
guettlibot guettli
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#349