13 Commits

Author SHA1 Message Date
6543
f0e56485dc Dummy backend support cancel (#6390) 2026-04-06 20:21:23 +02:00
6543
704245d96f Extend workflow integration tests (#6272) 2026-03-31 17:27:21 +02:00
6543
af471c5372 Fix pipeline cancel (#6320) 2026-03-30 19:33:54 +02:00
6543
fde1d917e2 Refactor pipeline runtime code (#6166)
Co-authored-by: Anbraten <6918444+anbraten@users.noreply.github.com>
2026-03-30 11:24:36 +03:00
qwerty287
79cc07265e Unify import aliases (#6328)
Co-authored-by: 6543 <6543@obermui.de>
2026-03-28 15:45:23 +01:00
6543
7a9f1ff2dc refactor move state.State.Workflow into own type (#6338) 2026-03-28 15:40:15 +01:00
6543
513011d1bf Forward skipped step state asap it is known (#6295) 2026-03-22 18:20:44 +01:00
6543
0214e4cd33 Only add compatibility environment variables for drone-ci to plugins (#6271) 2026-03-21 19:40:34 +01:00
6543
60a4d09f16 Add workflow integration test (#6270) 2026-03-21 11:54:48 +01:00
6543
09327abd03 Creating new engine runtime now requires backend as argument (#6268) 2026-03-20 13:44:24 +01:00
6543
b6c8c8b885 refactor: pipeline runtime add description and prevent race (#6167) 2026-03-08 09:50:11 +01:00
Harri Avellan
25842498c6 Prevent leaking goroutines on cancelled steps (#6186)
I've been debugging case where Kubernetes backend agents occasionally are OOMKilled. During the investigation noticed an increasing amount of goroutines on the agent processes which turned out to be multiple goroutines hanging on:
```
runtime.gopark(proc.go:461)
runtime.chanrecv(chan.go:667)
runtime.chanrecv1(chan.go:509)
go.woodpecker-ci.org/woodpecker/v3/pipeline/backend/kubernetes.(*kube).WaitStep(kubernetes.go:325)
go.woodpecker-ci.org/woodpecker/v3/pipeline/runtime.(*Runtime).exec(executor.go:261)
go.woodpecker-ci.org/woodpecker/v3/pipeline/runtime.(*Runtime).execAll.func1.1(executor.go:174)
go.woodpecker-ci.org/woodpecker/v3/pipeline/runtime.(*Runtime).execAll.func1.2(executor.go:200)
runtime.goexit(asm_arm64.s:1268)
go.woodpecker-ci.org/woodpecker/v3/pipeline/runtime.(*Runtime).execAll.func1(executor.go:199)
```

My analysis is that on cancel nothing fires the `finished` channel, as pod is deleted i.e. not updated (there's a registed handler for pod update events). There was already a comment about adding cancellation handler for ctx.Done, so I think this is the proper way (instead of adding event handler for pod deletion).
2026-03-02 20:14:56 +00:00
6543
a63b93f5ee Refactor pipeline engine (#6073)
restructure pipeline/*.go to use submodules

<!-- https://claude.ai/chat/1b8965d7-5bca-42c7-86b4-48c2d645c362 -->

- pipeline/error.go -> pipeline/errors/...
- pipeline/pipeline.go#Runtime -> pipeline/runtime/runtime.go
- pipeline/pipeline.go#execAll -> pipeline/runtime/executor.go
- pipeline/shutdown.go -> pipeline/runtime/shutdown.go
- pipeline/logger.go ->pipeline/logging
- pipeline/tracer.go -> pipeline/tracing
- pipeline/pipeline.go#State -> state/state.go
2026-02-13 11:56:43 +01:00