Skip to content

Support running only a single workflow per agent run#6150

Open
cliffmccarthy wants to merge 4 commits intowoodpecker-ci:mainfrom
cliffmccarthy:single-workflow
Open

Support running only a single workflow per agent run#6150
cliffmccarthy wants to merge 4 commits intowoodpecker-ci:mainfrom
cliffmccarthy:single-workflow

Conversation

@cliffmccarthy
Copy link

This is an updated version of #4019, based on the current main branch. This supports the use case of having the agent itself be ephemeral, which may be useful in various situations, including use of the local backend.

See commit messages for details and revision history. The first commit preserves attribution to @theanurin, who wrote most of this change; I just rebased it and made minor revisions.

theanurin and others added 2 commits February 22, 2026 11:05
- Added log message before canceling in error case.
- Return after calling ctxCancel.
- This makes the control flow for the single-workflow case match what
  it was in the original implementation of woodpecker-ci#4019.  As of commit
  5c9fc61, the 'err' value is never
  propagated to the caller, so this implementation returns nil.
- Fixed grammar in startup log message.
Copy link
Contributor

@qwerty287 qwerty287 left a comment

Choose a reason for hiding this comment

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

Thanks!

- Changes provided in review by qwerty287.

Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
@cliffmccarthy
Copy link
Author

I built and ran the latest revisions and it looks good from my end.

@woodpecker-bot
Copy link
Contributor

woodpecker-bot commented Feb 23, 2026

Surge PR preview deployment succeeded. View it at https://woodpecker-ci-woodpecker-pr-6150.surge.sh

@qwerty287
Copy link
Contributor

Thanks! Wouldn't it be better to directly use the stopAgentFunc func instead of ctxCancel?

@cliffmccarthy
Copy link
Author

Wouldn't it be better to directly use the stopAgentFunc func instead of ctxCancel?

I'll defer to you on which way it should operate. I tried changing it to call stopAgentFunc, and it appears to work, though I'm not sure I understand the intended flow with stopAgentFunc. When it is called from the single workflow conditional, I think stopAgentFunc gets called twice, once from the direct call, and once from the original defer. The definition of stopAgentFunc reassigns the symbol to a null function, but I don't think that changes the effect of the defer; I think the defer binds to the original definition of the function at the time it is deferred, based on my experiments.

@qwerty287
Copy link
Contributor

@6543 you introduced this stopAgentFunc logic. What do you say?

@cliffmccarthy
Copy link
Author

I studied stopAgentFunc some more and now I'm confident I don't understand it and the code associated with it. I don't think stopAgentFunc needs to be a global, or even a symbol at all; I think it could be deferred as a three-line anonymous function with no argument (because the argument is always nil). Where I get lost is in the globals shutdownCancelFunc and shutdownCtx. These seem to be involved in cases where run() gets called multiple times. The first call to run() defers a no-op shutdownCancelFunc; subsequent runs defer the shutdownCancelFunc that was set in the deferred operation of the previous call to run(). There's some sort of state machine here with global state between calls; I'm not familiar enough with how these contexts are being used to assess what the purpose of this code flow is, and whether it should be involved in what we do when we decide to exit the program after running a single workflow. It seems to me that calling ctxCancel() is probably the right way to initiate the shutdown, but I can't say that with confidence.

@qwerty287
Copy link
Contributor

@cliffmccarthy please have some patience. @6543 will check this out when he has time for it...

@cliffmccarthy
Copy link
Author

Thanks for following up! There's no rush from my end; feel free to proceed with this PR and any revisions as you see fit whenever your schedule allows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

agent enhancement improve existing features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants