feat!: db driven platform settings

[plyr4]

see: go-vela/community#921

• creates a singleton database record that persists platform settings across all servers
• settings are initialized using the standard flag flow
• middleware refreshes settings on each request

introduces some new admin api endpoints

• api/v1/admin/settings GET PUT to retrieve and update
• api/v1/admin/settings DELETE to "restore" the settings record to the original values stored in the server environment
• there is no POST because a user should never be responsible for creating settings records

NOTE: more fields need to be migrated, this is not an exhaustive implementation!

[codecov]

Codecov Report

Attention: Patch coverage is 69.18103% with 143 lines in your changes are missing coverage. Please review.

Project coverage is 68.08%. Comparing base (4421e30) to head (f54aa67).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1110      +/-   ##
==========================================
- Coverage   68.08%   68.08%   -0.01%     
==========================================
  Files         394      410      +16     
  Lines       13287    13691     +404     
==========================================
+ Hits         9047     9321     +274     
- Misses       3731     3836     +105     
- Partials      509      534      +25     

Files	Coverage Δ
compiler/native/clone.go	100.00% <100.00%> (ø)
compiler/native/compile.go	71.63% <100.00%> (ø)
compiler/native/expand.go	69.18% <100.00%> (ø)
compiler/native/native.go	88.63% <100.00%> (+0.68%)	⬆️
compiler/native/parse.go	86.51% <100.00%> (ø)
database/database.go	58.00% <ø> (ø)
database/resource.go	78.62% <100.00%> (-0.24%)	⬇️
database/settings/opts.go	100.00% <100.00%> (ø)
database/settings/table.go	100.00% <100.00%> (ø)
internal/image/image.go	100.00% <100.00%> (ø)
... and 26 more

[wass3r]

was running it locally and playing with the interval. i set it to one minute¹. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. {"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"} ↩

[plyr4]

was running it locally and playing with the interval. i set it to one minute1. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. `{"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"}` [↩](#user-content-fnref-1-686535cfb043439d3072d553cf6370a0)

that makes sense, UpdateSettings retrieves and updates the shared pointer. refresh loop is useful for broadcasting changes across multiple server instances. perhaps i could add a note to the logs to make that more clear?

[wass3r]

was running it locally and playing with the interval. i set it to one minute1. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. `{"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"}` [↩](#user-content-fnref-1-686535cfb043439d3072d553cf6370a0)

that makes sense, UpdateSettings retrieves and updates the shared pointer. refresh loop is useful for broadcasting changes across multiple server instances. perhaps i could add a note to the logs to make that more clear?

dang it. i swear i looked there and thought it just updated DB, not the in-memory settings 😲 i will run through it again. sorry.

i think we should make a note somewhere. what if folks want to use the interval as a safety-buffer. you know, to allow time for undoing an accidental change? that wouldn't be possible in this set up. arguably an edge case?

[plyr4]

was running it locally and playing with the interval. i set it to one minute1. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. `{"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"}` [↩](#user-content-fnref-1-686535cfb043439d3072d553cf6370a0)

that makes sense, UpdateSettings retrieves and updates the shared pointer. refresh loop is useful for broadcasting changes across multiple server instances. perhaps i could add a note to the logs to make that more clear?

dang it. i swear i looked there and thought it just updated DB, not the in-memory settings 😲 i will run through it again. sorry.

i think we should make a note somewhere. what if folks want to use the interval as a safety-buffer. you know, to allow time for undoing an accidental change? that wouldn't be possible in this set up. arguably an edge case?

seems like an edge case but i can totally understand the confusion. i mean it would be extremely easy to just use a different pointer and let the loop refresh it in the background, i suppose at least it would make things consistent/more straightforward. ill make the tweak

[wass3r]

was running it locally and playing with the interval. i set it to one minute1. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. {"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"} ↩

that makes sense, UpdateSettings retrieves and updates the shared pointer. refresh loop is useful for broadcasting changes across multiple server instances. perhaps i could add a note to the logs to make that more clear?

dang it. i swear i looked there and thought it just updated DB, not the in-memory settings 😲 i will run through it again. sorry.

i think we should make a note somewhere. what if folks want to use the interval as a safety-buffer. you know, to allow time for undoing an accidental change? that wouldn't be possible in this set up. arguably an edge case?

seems like an edge case but i can totally understand the confusion. i mean it would be extremely easy to just use a different pointer and let the loop refresh it in the background, i suppose at least it would make things consistent/more straightforward. ill make the tweak

Yes, I guess the more impactful scenario is that the bigger the interval the longer you will see inconsistent behavior because only one server will have the update (which makes a perhaps unreasonable assumptions that all servers start at the same time). Thanks! But maybe I'm making an elephant out of a mosquito here 😅

[plyr4]

was running it locally and playing with the interval. i set it to one minute1. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. {"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"} ↩

that makes sense, UpdateSettings retrieves and updates the shared pointer. refresh loop is useful for broadcasting changes across multiple server instances. perhaps i could add a note to the logs to make that more clear?

dang it. i swear i looked there and thought it just updated DB, not the in-memory settings 😲 i will run through it again. sorry.

i think we should make a note somewhere. what if folks want to use the interval as a safety-buffer. you know, to allow time for undoing an accidental change? that wouldn't be possible in this set up. arguably an edge case?

seems like an edge case but i can totally understand the confusion. i mean it would be extremely easy to just use a different pointer and let the loop refresh it in the background, i suppose at least it would make things consistent/more straightforward. ill make the tweak

Yes, I guess the more impactful scenario is that the bigger the interval the longer you will see inconsistent behavior because only one server will have the update (which makes a perhaps unreasonable assumptions that all servers start at the same time). Thanks! But maybe I'm making an elephant out of a mosquito here 😅

heres the update: 4cad3e6

i'll let you make the call on keeping it or reverting it. i dont mind either way.

[wass3r]

was running it locally and playing with the interval. i set it to one minute1. however, any change to settings i would make (i was using clone image in this case) would always immediately apply.

Footnotes

1. {"level":"info","msg":"refreshing platform settings every 1m0s","time":"2024-05-10T13:22:27Z"} ↩

that makes sense, UpdateSettings retrieves and updates the shared pointer. refresh loop is useful for broadcasting changes across multiple server instances. perhaps i could add a note to the logs to make that more clear?

dang it. i swear i looked there and thought it just updated DB, not the in-memory settings 😲 i will run through it again. sorry.

i think we should make a note somewhere. what if folks want to use the interval as a safety-buffer. you know, to allow time for undoing an accidental change? that wouldn't be possible in this set up. arguably an edge case?

seems like an edge case but i can totally understand the confusion. i mean it would be extremely easy to just use a different pointer and let the loop refresh it in the background, i suppose at least it would make things consistent/more straightforward. ill make the tweak

Yes, I guess the more impactful scenario is that the bigger the interval the longer you will see inconsistent behavior because only one server will have the update (which makes a perhaps unreasonable assumptions that all servers start at the same time). Thanks! But maybe I'm making an elephant out of a mosquito here 😅

heres the update: 4cad3e6

i'll let you make the call on keeping it or reverting it. i dont mind either way.

i like the change. i think that is expected behaviour in a single instance scenario and it gives you the option of close consistency in multi-server scenario. thank you!

[wass3r]

nice work 😍

[ecrupper]

Suggested change

	func FromAPI(s *settings.Platform) *Platform {
	func SettingsFromAPI(s *settings.Platform) *Platform {

Sorry just caught this. Need to have the resource part of the name if they are all in the types package.

[plyr4]

cool cool lemme tweak it

[ecrupper]

Will address in follow up PR

[plyr4]

#1126 🙇