Feat: IssueDetails test and build info #711
Conversation
MarceloRobert
force-pushed
the
feat/issue-details-incidents
branch
from
2085926 to
8bc117d
Compare
dashboard/src/components/BuildDetails/BuildDetailsTestSection.tsx
Outdated
Show resolved
Hide resolved
MarceloRobert
force-pushed
the
feat/issue-details-incidents
branch
from
8bc117d to
2f37bb0
Compare
| missing_params = [] | ||
| if issue_id is None: | ||
| missing_params.append("issue_id") | ||
| if version is None: | ||
| missing_params.append("version") | ||
| if len(missing_params) != 0: | ||
| return HttpResponseBadRequest( | ||
| getErrorResponseBody("Missing parameters: ", missing_params) | ||
| ) | ||
|
|
There was a problem hiding this comment.
II'm pretty sure you can validate the parameters with pydantic
| parsed_version = int(version) | ||
| except ValueError: | ||
| return HttpResponseBadRequest( | ||
| getErrorResponseBody("Invalid version parameter, must be an integer") |
There was a problem hiding this comment.
we have create_error_response now
| builds_data = self._fetch_incidents(issue_id=issue_id, version=parsed_version) | ||
|
|
||
| if builds_data is None: | ||
| return HttpResponseNotFound(getErrorResponseBody("Builds not found")) |
There was a problem hiding this comment.
ditto about create error response
| missing_params = [] | ||
| if issue_id is None: | ||
| missing_params.append("issue_id") | ||
| if version is None: | ||
| missing_params.append("version") | ||
| if len(missing_params) != 0: | ||
| return HttpResponseBadRequest( |
There was a problem hiding this comment.
ditto for pydantic and create_error_response
| @@ -94,6 +101,21 @@ export const sanitizeBuilds = ( | |||
| })); | |||
| }; | |||
|
|
|||
| export const sanitizeBuildTable = ( | |||
There was a problem hiding this comment.
This is creating an O(2N), and sometimes N equals 600000, maybe it is better to create an object with the sanitizers and place them on the row definition, but the only way of knowing is if we measure. I think this is okay for now but lets keep that in mind
There was a problem hiding this comment.
The 600000 figure is for tests related to an issue, for builds the number is much lower. But I agree we should fix the typing of builds so that we won't need all this conversion.
|
It is working nice, just some comments |
MarceloRobert
force-pushed
the
feat/issue-details-incidents
branch
from
2f37bb0 to
e4648b4
Compare
Adds /issues/<issue_id>/version//tests endpoint to get all tests related to an issue
Adds /issues/<issue_id>/version//builds endpoint to get all builds related to an issue
Adds request for these endpoints from the frontend
Adds a SectionError component for when a table in a details page can't load and refactors its use in BuildDetailsTestSection
Adds a TestsTable to the IssueDetails page when the current issue is related to a test
Adds a BuildsTable to the IssueDetails page when the current issue is related to a test
The relation with tests and builds are intuitively mutually exclusive, but - since the database allows for both
test_statusandbuild_validto be not null in a single issue - it is technically possible for an issue to be associated with tests and builds at the same time. There are no issues related to both tests and builds currently.It's also possible for an issue to not be related with either tests or builds, but there are no occurrences of that for the maestro origin, only for redhat.
How to test
Go to an IssueDetails page with an issue related to tests and see the test table, such as this example:
http://localhost:5173/issue/maestro%3Af627e08f767a688209f3f9a2d41c6b4c260897b0/version/0
Go to an IssueDetails page with an issue related to builds and see the builds table, such as this example:
http://localhost:5173/issue/maestro:a8ba4fd7ab9f996d9e569f77d5cf91354e7a783b/version/0
An issue with no relation to either tests or builds for example: http://localhost:5173/issue/redhat:issue_2089/version/1727692707
Closes #705