-
Notifications
You must be signed in to change notification settings - Fork 362
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
New endpoint to create internal issues before submitting a bug #8443
Conversation
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.
in general I think this needs to:
- convert lines to "single tracking bugs" where it can. This would mean finding a test name and ignoring the raw error message that comes after the test name.
- keep track of the failures (job ids should be enough), primarily so when we do create the bug it will be linked properly to all the failures.
def create(self, validated_data): | ||
failure_line = validated_data["failure_line"] | ||
|
||
# TODO: Fetch all the similar failure lines |
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.
For awareness and understanding: In general, the failure lines classified with an internal issue will be similar but they could also be different because they have a common root cause which is not logged in the failure line, e.g. a random focus issue of the browser engine or test framework can cause various form tests to fail. The canonical source for occurrences remain the classifications from Bugscache.
@Archaeopteryx from the discussion we had I assumed the UI to look like something like this: This is the actual battle plan in my head:
|
The
The code sheriffs have been asked for additional feedback which I will share here if there is any. |
22d704c
to
894f43d
Compare
), | ||
migrations.AddField( | ||
model_name="bugscacheoccurrence", | ||
name="text_log_error", |
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.
Treeherder stores classifications of jobs (tasks) with bugs (internal issues in the future) which get suggested for failure lines. Based on the discussion last week, I think we should keep that concept.
The unique combination should job + internal issue ID.
@Archaeopteryx I started working on the frontend. One thing I noticed is that everything relies on a Bugzilla ID there (for classification an ID may be typed directly, or we would prefer to use I can update the M2M so it links the Job to the Internal issue. Through in this case it would be better to reuse I can probably make a separate PR to remove the M2M and update BugJobMap to enforce Foreign key to Bugscache internal ID (and patching scripts that manipulates this table). |
* Update redux store * Update related components This will also require to update the API to support both references.
This endpoint will be updated anyway as we now serialize occurences in /bug_suggestions/
About users manually entering the ID to use for classification: |
I'm closing this. Thank you for the many explanations, from my current understanding here are the next steps I can work on (split in 3 different PRs):
|
Recommendation: Always show internal one, and bugzilla when available. |
No description provided.