-
Notifications
You must be signed in to change notification settings - Fork 0
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
Adding GitHub Workflow Parser #7
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: vsoch <[email protected]>
Signed-off-by: vsoch <[email protected]>
Signed-off-by: vsoch <[email protected]>
Md5 of full traceback might be too rigid. I would have made it a tripple hierarchy:
Such levels could allow for matching similar even if not identical issues on client side (eg full repo could be cloned and updated in the cache). GitHub action could be used to make records of new issues (which would already have that composite fingerprint in them already).. although there might be benefits from collecting additional traceback and wtf details for already existing issues, I am afraid it might be too much chatter if we are to monitor this collection of issues |
Okay so just to make sure I have it right, you would do (these are just randomly derived values so we can see what it looks like)
So you are proposing it would look like:
If the traceback is part of the md5, and it's included in the issue, we would definitely be storing it. For the line numbers, I think that's probably overkill for the points that you mentioned. My 0.02 for the above - I think the specific dependency lists and functions list might be too detailed for grouping errors. If we have an exception name, and then md5 based on the traceback, I think that could be enough for a human to browse, and to match issues that belong together. On the other hand, you are thinking that you would want to search based on md5 of just a functions list, or just a hash of functions? I have mixed feelings about this, because I don't think I fully understand what a functions list is. My instinct is that we should start with a simpler (less detailed) approach and only dive into more detail if we find it doesn't work well (meaning that two exceptions are labeled as the same but are very different to resolve / address, or we need to search for something and find that we cannot). |
okay actually I think I figured it out re: the lists:
|
Signed-off-by: vsoch <[email protected]>
Signed-off-by: vsoch <[email protected]>
okay just updated the script here to use the updated (more specific) hash. |
This is a first shot at adding the parser as a GitHub action to, when an issue is submit:
This should serve two fold - to both help the user, and keep a little database of issues reported. I suspect we will want to get a base merged, and then tweak details once the datalad PR is merged and we can adjust.