feat: request up to capacity jobs from Forgejo in one API call #1245
No reviewers
Gusted
Labels
No labels
FreeBSD
Kind/Breaking
Kind/Bug
Kind/Chore
Kind/DependencyUpdate
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Windows
linux-powerpc64le
linux-riscv64
linux-s390x
run-end-to-end-tests
run-forgejo-tests
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
forgejo/runner!1245
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "mfenniak/forgejo-runner:fetchtask-mutliple"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Permits the Runner to fetch multiple tasks from Forgejo in one API call, up to the configured capacity (minus any running jobs).
In the event that Forgejo doesn't support the
TaskCapacityparameter (eg. current Forgejo), this implementation continues to performFetchTaskoperations retrieving one task every configuredFetchInterval, which is the same as the current behaviour. The implementation is changed so that this is done in a single goroutine rather than one goroutine per capacity, but the behaviour is the same -- the interval was implemented through a shared rate limiter before, and now only has a single goroutine waiting on the same rate limiter.testing/synctestis used to create neat unit tests for the new behaviour. They look very fragile with millisecond precision waits, but are not due to synctest.Related Forgejo PR: https://codeberg.org/forgejo/forgejo/pulls/10602
capacityjobs from Forgejo in one API call@ -77,0 +93,4 @@log.Tracef("[poller] successfully fetched %d tasks", len(tasks))for _, task := range tasks {inProgressTasks.Add(1)wg.Add(1)Suppose you could make use of
wg.Do@ -77,0 +95,4 @@inProgressTasks.Add(1)wg.Add(1)go func() {p.runTaskWithRecover(p.jobsCtx, task)https://go.dev/blog/loopvar-preview, you're lucky :)
I am aware of this gotcha, but my awareness ends roughly around "it's fine to ignore this problem now". 🤣
@ -77,1 +102,4 @@}}}Trace message that indicates shutdown initiated/handling, waiting until all tasks are complete? Given you added the other trace message.
There's an info-level msg before the loop
breakindicating that shutdown began.80e135d23a82bf86650582bf86650561134cdf0961134cdf09ebfdf283a4WIP: feat: request up toto feat: request up tocapacityjobs from Forgejo in one API callcapacityjobs from Forgejo in one API call