Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(repo)!: change allow_<event> fields to an AllowEvents struct + DB use integer masking #314

Merged
merged 24 commits into from
Dec 8, 2023

Conversation

ecrupper
Copy link
Contributor

Ref: go-vela/community#828

This change lays the groundwork for enhanced event support moving forward by leveraging a bit-shifting iota type for allowed events represented in the database and a new struct for AllowEvents in the library.

This helps future development of events (and event actions) by not impacting the database. Plus, it allows a clean representation of data for the UI to interpret when the AllowEvents struct can be transformed into a nested checklist.

@ecrupper ecrupper self-assigned this Sep 15, 2023
@ecrupper ecrupper requested a review from a team as a code owner September 15, 2023 17:13
@codecov
Copy link

codecov bot commented Sep 15, 2023

Codecov Report

Merging #314 (e7bc0a6) into main (b43cd77) will decrease coverage by 0.27%.
The diff coverage is 89.76%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #314      +/-   ##
==========================================
- Coverage   96.38%   96.11%   -0.27%     
==========================================
  Files          62       67       +5     
  Lines        6920     7213     +293     
==========================================
+ Hits         6670     6933     +263     
- Misses        181      205      +24     
- Partials       69       75       +6     
Files Coverage Δ
database/repo.go 98.35% <100.00%> (+0.04%) ⬆️
library/actions/deploy.go 100.00% <100.00%> (ø)
library/actions/push.go 100.00% <100.00%> (ø)
library/actions/comment.go 92.30% <92.30%> (ø)
library/actions/pull.go 94.54% <94.54%> (ø)
library/repo.go 97.69% <75.00%> (-2.31%) ⬇️
library/events.go 84.78% <84.78%> (ø)

@ecrupper ecrupper marked this pull request as draft September 15, 2023 17:17
@ecrupper ecrupper marked this pull request as ready for review September 15, 2023 17:29
library/repo_test.go Outdated Show resolved Hide resolved
library/repo_test.go Show resolved Hide resolved
Comment on lines 9 to 16
AllowPushBranch = 1 << iota // 00000001 = 1
AllowPullOpen // 00000010 = 2
AllowPullEdit // 00000100 = 4
AllowPullSync // ...
AllowPushTag
AllowDeployCreate
AllowCommentCreate
AllowCommentEdit
Copy link
Contributor Author

Choose a reason for hiding this comment

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

A note on this: we can't shuffle these at any point if this were to be implemented. So, if a pull_request event with the action review_requested is something we support later, then it must go at the bottom.

Copy link
Member

@wass3rw3rk wass3rw3rk Sep 18, 2023

Choose a reason for hiding this comment

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

seems like a good thing to add to comments in-line oops, you did already - didn't show in a diff view i was looking at for some reason.

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 introduce some kind of version bit (byte?) so that the entire thing can be invalidated in the future? For now, just include the bit. Then, the migration logic can be introduced when we bump that version, if we ever do so.

Copy link
Member

Choose a reason for hiding this comment

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

Since we're using Intl64, and so far this only uses 8 bits, So, the version info could actually be at the end of the 64 bits instead of the beginning. Then, we don't need to reserve any space.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My hesitation with including a version is that it would require some sort of DB migration script that updates all existing repos every time we add a new event we support. Part of me wants to just go in and enumerate all possible webhook actions that Vela could theoretically subscribe to and just mark them as not implemented if they aren't. That way future enhancements would build off a clean order and it wouldn't change unless GitHub itself adds a new event / action worth implementing.

Copy link
Member

Choose a reason for hiding this comment

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

Yes. Let's leave room for all current GitHub events, but leave a _ for all of the unimplemented ones with a comment saying what that slot is reserved for. Maybe even leave a bit of a gap in each category to add more later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added space for future implementations for pull_request actions that seem potentially relevant to CI

Copy link
Member

Choose a reason for hiding this comment

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

There seems to be a lot of other possible webhook events:
https://docs.github.com/en/webhooks/webhook-events-and-payloads

How did you pick which of the pull_request actions deserved an entry here?

@ecrupper ecrupper added the v0.22.0 Content slotted for v0.22.0 release label Sep 18, 2023
constants/allow_events.go Outdated Show resolved Hide resolved
library/event_actions.go Outdated Show resolved Hide resolved
library/events.go Outdated Show resolved Hide resolved
@ecrupper ecrupper added v0.23.0 and removed v0.22.0 Content slotted for v0.22.0 release labels Oct 24, 2023
@ecrupper
Copy link
Contributor Author

After some discussion amongst the @go-vela/admins, we are deciding to:

  1. Move this to v0.23.0
  2. Keep the DB fields of AllowPush, AllowPull, AllowDeploy, AllowTag, and AllowComment to preserve the data when we decide to upgrade to this new AllowEvents model. This will make migration scripting easier.
  3. Deprecate those fields and then plan on dropping them with the release of v0.24.0.

@ecrupper ecrupper marked this pull request as draft October 24, 2023 16:08
@ecrupper ecrupper marked this pull request as ready for review November 14, 2023 16:15
constants/allow_events.go Outdated Show resolved Hide resolved
Copy link
Contributor

@KellyMerrick KellyMerrick left a comment

Choose a reason for hiding this comment

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

lgtm

Copy link
Member

@wass3rw3rk wass3rw3rk left a comment

Choose a reason for hiding this comment

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

let's go to the moon 🌑

@ecrupper ecrupper merged commit 23c1585 into main Dec 8, 2023
10 checks passed
@ecrupper ecrupper deleted the feat-iota-event-matrix branch December 8, 2023 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants