Skip to content

Conversation

adelowo
Copy link
Member

@adelowo adelowo commented May 26, 2025

  • Added a periodic worker that evaluates all jobs
  • Takes a look at the next run time for a job, then adds to schedule_job_runs so an agent can pick up
  • Does a db clean up since the runs table can potentially get bloated. So every run that has it's exectution time in the past gets cleaned up
  • Supports templating using the configuration of the job. E.g the parent script provided by system admin or marketplace can use echo {{ .URL }} and in your config on the dashboard, you define {"ssl" : { "url" : "https://theopenlane.io"}, now {{.URL}} in your script will be replaced before the agent picks up to run

no tests here because I am not yet certain of the most optimal way to not have to duplicate/copy manually migrations files here

@github-actions github-actions bot added enhancement New feature or request jobs labels May 26, 2025
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 20%)

See analysis details on SonarQube Cloud

@adelowo adelowo marked this pull request as ready for review May 28, 2025 01:43
@adelowo adelowo requested a review from a team as a code owner May 28, 2025 01:43
@@ -110,6 +114,16 @@ func New(ctx context.Context, opts ...Option) (c *Client, err error) {
}
}

c.config.RiverConf.PeriodicJobs = append(c.config.RiverConf.PeriodicJobs,
river.NewPeriodicJob(
river.PeriodicInterval(1*time.Minute),
Copy link
Member Author

Choose a reason for hiding this comment

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

Should this be configurable? I am thinking a default of maybe 3-4 minutes might be better

// DatabaseHost for connecting to the postgres database
// This is for the core server database which can potentially be different from
// river queue's
DatabaseHost string `koanf:"databaseHost" json:"databaseHost" default:"postgres://postgres:password@0.0.0.0:5432/jobs?sslmode=disable"`
Copy link
Member

Choose a reason for hiding this comment

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

This is already defined in the main river config: https://github.com/theopenlane/riverboat/blob/6d676116ba67bd3b1a38ae08b8f45c4a1f9f58b0/internal/river/config.go#L11C2-L11C14

Although the comment makes me think you want core instead of jobs? If that is the case - we shouldn't allow river to directly connect to the database.

g.SetLimit(maxConcurrentJobs)

for {
query := `
Copy link
Member

Choose a reason for hiding this comment

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

Can we use the API for this instead? This is potentially fragile and ideally river doesn't need direct DB access to core


// Work evaluates the available jobs and marks them as ready to be executed by agents if needed
func (s *ScheduledJobWorker) Work(ctx context.Context, _ *river.Job[ScheduledJobArgs]) error {
if err := s.validateConnection(); err != nil {
Copy link
Member

Choose a reason for hiding this comment

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

Instead of querying the API - can we just insert a job from core in a hook with the cron config and let river handle all the scheduling?

@adelowo adelowo marked this pull request as draft May 28, 2025 22:28
@adelowo
Copy link
Member Author

adelowo commented May 29, 2025

this is moving into core now

@adelowo adelowo closed this May 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client enhancement New feature or request jobs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants