-
Notifications
You must be signed in to change notification settings - Fork 29
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: add service info endpoint #192
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
@sourcery-ai review |
🧙 Sourcery is reviewing your pull request! Tips
|
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.
Hey @JaeAeich - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟡 General issues: 4 issues found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.
@@ -0,0 +1,55 @@ | |||
"""RFC3339 date validator.""" |
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.
suggestion: Validator class naming
Consider renaming the class RFC3339 to RFC3339Validator for consistency and clarity, especially since the docstring refers to it as RFC3339Validator.
"""RFC3339 date validator.""" | |
"""RFC3339Validator date validator.""" |
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.
you should rename this with the purpose this validator serves or consider it in the deinition.
@@ -0,0 +1,35 @@ | |||
"""Base class for TES API pydantic models.""" |
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.
issue (bug_risk): Validator import
The import for RFC2386 should be corrected to RFC2368 to match the correct RFC for email validation.
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 incorporate this?
@@ -0,0 +1,24 @@ | |||
"""RFC2386 email validator.""" |
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.
issue (bug_risk): Incorrect RFC number
The correct RFC for email validation is RFC 2368, not RFC 2386. Please update the class name and references accordingly.
@@ -0,0 +1,33 @@ | |||
"""RFC3986 URL validator.""" |
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.
suggestion: Validator class naming
Consider renaming the class RFC3986 to RFC3986Validator for consistency and clarity, especially since the docstring refers to it as RFC3986Validator.
"""RFC3986 URL validator.""" | |
"""RFC3986Validator URL validator.""" |
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.
Please incorporate the comments.
"""Base class for the TES API. | ||
|
||
This class is an abstract class that defines the common properties and | ||
methods needed by all of the TES API endpoint business logic. | ||
""" | ||
|
||
def __init__(self) -> None: |
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.
IMO we should keep a default init.
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.
BaseTeskRequest
is implementing ABC, would we initialize super still?
# Get logger instance | ||
logger = logging.getLogger(__name__) | ||
|
||
service_info = ServiceInfo() |
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 define this in the method itself?
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.
If someone keeps hitting this endpoint, why initialise the the obj again and again, either way it is not supposed to change or be that fickel, in that case it makes more sense to give cached result.
PS: The case will be diff when/if we implement post service endpoint.
"a different namespace (e.g. your organization's reverse domain name)." | ||
), | ||
) | ||
artifact: Literal['tes'] = Field( |
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 Literal?
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.
because its "Literal"ly just tes in the specs. It mentions enum there, but since there wont be anything but tes why not use literal.
r'^(?:http|ftp)s?://' # http:// or https:// | ||
r'(?:(?:[A-Z0-9](?:[A-Z0-9-]{0,61}[A-Z0-9])?\.)+' # domain part 1 | ||
r'(?:[A-Z]{2,6}\.?|[A-Z0-9-]{2,}\.?)|' # domain part 2 | ||
r'localhost|' # localhost... |
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.
is this correct?
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 have tested with limited set of URLs and that seems to be correct afaik 😭, maybe better use the pydantic type HttpURL.
from tesk.tesk_app import TeskApp | ||
|
||
|
||
class BaseServiceInfoRequest(BaseTeskRequest): |
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.
Do we really need this? Do you think there is a possibility of multiple input service info request?
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.
yeah this one I don't really need this one specifically but since I will def need similar "interface" in task
endpoint for consistency, I implemented interface for service
as well.
tesk/api/ga4gh/tes/service_info/base/base_service_info_request.py
Outdated
Show resolved
Hide resolved
4ed93c7
to
04740aa
Compare
please check #198 |
fixed - #157
Summary by Sourcery
This pull request adds a new service info endpoint to the TES API, providing comprehensive details about the service. It also includes significant refactoring of the TeskApp class to streamline initialization and updates the deployment configuration to support the new service info settings.