-
Notifications
You must be signed in to change notification settings - Fork 43
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
Implement general entity registration for the GitHub provider #4376
Conversation
Minder Vulnerability Report ✅Minder analyzed this PR and found it does not add any new vulnerable dependencies.
|
8c236a4
to
61a3232
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love that this is overall producing less code, and providing a general cleanup / garbage-collection mechanism.
return errors.New("repo owner property not found") | ||
} | ||
|
||
hookIDP := props.GetProperty(ghprop.RepoPropertyHookId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these the same properties used for selectors? Does this mean that I could write a selector on the GitHub webhook ID?
I'm not trying to stir things up, just trying to test my understanding of the changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes they are, we are piggy backing that functionality. We are yet to define a way to filter out properties for certain functionality. One case where that would be handy is displaying: We'd want to mark some properties as displayable and some not. Being able to filter in selectors might be a similar if not the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
specifically for the hook ID - since this is not an attribute that you can get with an upstream call (well you can list all the webhooks but then you get them all and you need to figure out yourself which hooks are yours), the properties module treats the attribute as "operational", that is, it won't ever try to fetch it from provider and if replacing attributes for an entity, the property module won't replace an operational attribute.
So an easy thing we could do would be to just not pass the operational properties to the selectors.
-- GetEntitiesByProvider retrieves all entities of a given provider. | ||
-- this is how one would get all repositories, artifacts, etc. for a given provider. | ||
|
||
-- name: GetEntitiesByProvider :many |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can / should we include a project ID in here to avoid potential confused-deputy problems like GHSA-v627-69v2-xx37 ? (I realize we might have other defenses, but that bug has made me a bit paranoid.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, we can! I regret not having an index for provider + project.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh! Yeah, this is going to get tricky since a provider can live in a parent project, and the entities originating from that provider can be in subprojects. Now I remember why this was done without the ProjectID as part of the query.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we pass a list of projects that are subprojects of the provider?
(I am guilty of removing the project ID from the getByID call as well thinking that "well, the ID is unique" and forgot about that potential issue as well)
d0257ab
to
b0d4f90
Compare
b0d4f90
to
21fbfd6
Compare
return errors.New("repo owner property not found") | ||
} | ||
|
||
hookIDP := props.GetProperty(ghprop.RepoPropertyHookId) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
specifically for the hook ID - since this is not an attribute that you can get with an upstream call (well you can list all the webhooks but then you get them all and you need to figure out yourself which hooks are yours), the properties module treats the attribute as "operational", that is, it won't ever try to fetch it from provider and if replacing attributes for an entity, the property module won't replace an operational attribute.
So an easy thing we could do would be to just not pass the operational properties to the selectors.
|
||
err := c.DeleteHook(ctx, repoOwner, repoName, hookID) | ||
if err != nil { | ||
return fmt.Errorf("error deleting hook: %w", err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we treat this error that calls upstream and the errors where we don't have the required properties differently? e.g. the upstream call error could be transient and the user might just want to retry but if the properties are not there, then there's no point in retrying, shouldn't we just proceed with deleting the entity in that case?
-- GetEntitiesByProvider retrieves all entities of a given provider. | ||
-- this is how one would get all repositories, artifacts, etc. for a given provider. | ||
|
||
-- name: GetEntitiesByProvider :many |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we pass a list of projects that are subprojects of the provider?
(I am guilty of removing the project ID from the getByID call as well thinking that "well, the ID is unique" and forgot about that potential issue as well)
21fbfd6
to
ef0f33f
Compare
This moves around the webhook handling code into the general entity registration interface. Thus removing the need for the webhook manager. Instead, each provider implements it's own registration, which _could_ be webhook-based. The repo service was moved outside of the `github` package since it can now work in a more general manner. Fixes #4326 Signed-off-by: Juan Antonio Osorio <[email protected]>
ef0f33f
to
36c7449
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great. We can remove some more references to github in a follow up - e.g. I think we should no longer need pbRepoFromProperties
but instead could call RepoV1FromProperties and remove some more references to github from the generic code. But that's not blocking really.
Summary
This moves around the webhook handling code into the general entity
registration interface. Thus removing the need for the webhook manager.
Instead, each provider implements it's own registration, which could
be webhook-based.
The repo service was moved outside of the
github
package since it cannow work in a more general manner.
Fixes #4326
Change Type
Mark the type of change your PR introduces:
Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist: