Support one-shot agent execution mode

[cliffmccarthy]

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.

[qwerty287]

Thanks!

[cliffmccarthy]

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

[woodpecker-bot]

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

[qwerty287]

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

[cliffmccarthy]

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]

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

[cliffmccarthy]

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]

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

[cliffmccarthy]

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.

[qwerty287]

@6543 pinging you again… :)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 34.18%. Comparing base (926470f) to head (51aa308).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6150   +/-   ##
=======================================
  Coverage   34.18%   34.18%           
=======================================
  Files         426      426           
  Lines       28528    28528           
=======================================
  Hits         9751     9751           
  Misses      17887    17887           
  Partials      890      890           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.