-
Notifications
You must be signed in to change notification settings - Fork 25
Remove refs to InfrahubServices
for git ops
#6406
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
base: develop
Are you sure you want to change the base?
Conversation
This change tries to remove the need for a `InfrahubServices` object when it comes to operations to be performed on a git repository. This work is a stepping stone to be able to run user flagged workflows inside a dedicated prefect worker for isolation purpose as we won't be able to inject a `InfrahubServices` object into, also we don't want to for security reasons.
CodSpeed Performance ReportMerging #6406 will not alter performanceComparing Summary
|
def build_client() -> InfrahubClient: | ||
global client | ||
if client is None: | ||
client = InfrahubClient(config=Config(address=config.SETTINGS.main.internal_address, retry_on_failure=True)) | ||
return client | ||
|
||
|
||
@inject | ||
def get_client(client: InfrahubClient = Depends(build_client)) -> InfrahubClient: # noqa: B008 | ||
return client |
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.
Thinking about this one, I think we might want it not to be a singleton but instead having a fresh instance of the client each time a flow needs one and pass it down the line of tasks that also need it.
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.
Why?
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.
There are pros and cons to this, if we reuse the existing client it could be prepopulated with a schema so that we don't need to query the API, this can of course also be a bad thing if we don't actually want the schema to exist (perhaps it needs to be updated etc).
Another scenario is if our client will use the store, in that case perhaps we don't want to use the same client. We have the .clone method on the client and we could use other ways to determine what type of client we get depending on how we inject it. I think we can come back to that part once this is in place though.
|
||
return self.service.client | ||
return self.client |
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.
It could perhaps be a follow up PR but I think we should get rid of the sdk
property.
def build_client() -> InfrahubClient: | ||
global client | ||
if client is None: | ||
client = InfrahubClient(config=Config(address=config.SETTINGS.main.internal_address, retry_on_failure=True)) | ||
return client | ||
|
||
|
||
@inject | ||
def get_client(client: InfrahubClient = Depends(build_client)) -> InfrahubClient: # noqa: B008 | ||
return client |
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.
There are pros and cons to this, if we reuse the existing client it could be prepopulated with a schema so that we don't need to query the API, this can of course also be a bad thing if we don't actually want the schema to exist (perhaps it needs to be updated etc).
Another scenario is if our client will use the store, in that case perhaps we don't want to use the same client. We have the .clone method on the client and we could use other ways to determine what type of client we get depending on how we inject it. I think we can come back to that part once this is in place though.
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.
LGTM
This change tries to remove the need for a
InfrahubServices
object when it comes to operations to be performed on a git repository.This work is a stepping stone to be able to run user flagged workflows inside a dedicated prefect worker for isolation purpose as we won't be able to inject a
InfrahubServices
object into, also we don't want to for security reasons.