enhance(repo)!: add AllowSchedule field

[jbrockopp]

xref: go-vela/community#538

Part of go-vela/community#772

Based off of #289

This change add an AllowSchedule field to the Repo{} object:

types/database/repo.go

Line 71 in eb7c705

AllowSchedule sql.NullBool `sql:"allow_schedule"`

types/library/repo.go

Line 38 in eb7c705

AllowSchedule *bool `json:"allow_schedule,omitempty"`

Similar to the other Allow* fields, this will enable users to control if their repo responds to the schedule event.

Initially, I didn't plan to add this field since the Allow* fields control which git based events to respond to.

And schedules will be totally controlled by Vela (i.e. not SCM driven), and won't be an event for webhooks.

That being said, I wanted to start with opening this PR to collect feedback on if we should add this or not.

You can find an example of how this field will be used within go-vela/server#846.

NOTE: Marking this as a breaking change since it adds a new field which will require DB migrations.

[codecov]

Codecov Report

Merging #291 (eb7c705) into main (f538de0) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #291   +/-   ##
=======================================
  Coverage   97.00%   97.01%           
=======================================
  Files          59       59           
  Lines        6545     6562   +17     
=======================================
+ Hits         6349     6366   +17     
  Misses        145      145           
  Partials       51       51           

Impacted Files	Coverage Δ
database/repo.go	98.27% <100.00%> (+0.02%)	⬆️
library/repo.go	100.00% <100.00%> (ø)

[plyr4]

LGTM, seems like a straightforward way to disable repo schedules without actually removing the schedule or disabling event-driven builds. nice

[wass3r]

works for me, but i can see your hesitation about adding non-SCM events here. i think it's fine.

[jbrockopp]

@ecrupper @plyr4 @wass3r only one last caveat to point out and then I think we can merge 👍

The server scan's the entire schedules table for all schedules with active == true.

This would include any schedules for a repo that have the schedule event disabled.

This could mean the server spends unneeded extra cycles processing schedules for a repo with that event disabled.

We could perform a JOIN with the repos table to check for the event being disabled?

However, in general, I try to avoid JOIN queries since they can be taxing on the system especially for large tables.

[cognifloyd]

I think the per repo flag complicates things. It might be a good idea, but the global allow list is sufficient for now, so let's wait till after the rest of schedules are implemented and then work on adding the per-repo flag.

[wass3rw3rk]

@jbrockopp thanks for calling attention to that. i'm good with the approach @cognifloyd mentioned.

[jbrockopp]

@wass3rw3rk perhaps I misunderstood, but if we want to go with that approach we shouldn't merge this, right?

So I think we'll need to revert this PR and then I can open a new one with this change as a draft PR.

Otherwise, we'll be unable to pull this repo (as a go dependency) on the main branch into go-vela/server.