Feature #8706
closedPermanent (pretty) URLs for error traces
0%
Description
We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use job names provided by the users (seems that we need to enforce uniqueness of them) and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).
Updated by Evgeny Novikov almost 7 years ago
- Description updated (diff)
- Target version set to 2.0
Updated by Vladimir Gratinskiy almost 7 years ago
Vadim Mutilin wrote:
We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use launch names (identifiers) provided by the users (seems that we need to enforce uniqueness of them)
What does "launch names" mean? Identifiers of jobs? I didn't know that users can provide jobs identifiers.
and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).
It can't be kept. I will use identifers specified in error trace json file (comments for "error traces" in https://docs.google.com/document/d/1tLOsqCQxMRlDvSNXFmaGOSQqIL8PORNI-BEsfZP8hoQ/edit). So the link will be like "/reports/unsafe/<32-bit error trace identifer>".
Updated by Evgeny Novikov almost 7 years ago
- Description updated (diff)
Vladimir Gratinskiy wrote:
Vadim Mutilin wrote:
We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use launch names (identifiers) provided by the users (seems that we need to enforce uniqueness of them)What does "launch names" mean? Identifiers of jobs? I didn't know that users can provide jobs identifiers.
I fixed the issue description. It's about job names. And it does have sense to make them unique globally, but this is responsibility of an user.
and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).
It can't be kept. I will use identifers specified in error trace json file (comments for "error traces" in https://docs.google.com/document/d/1tLOsqCQxMRlDvSNXFmaGOSQqIL8PORNI-BEsfZP8hoQ/edit). So the link will be like "/reports/unsafe/<32-bit error trace identifer>".
I don't understand why this is necessary for the specified issue. Indeed Bridge can generate and use such the identifiers itself since they are required just for permanent and unique identification of error traces within various instances of Bridge (databases). Perhaps your approach can be helpful for debugging, e.g. when Bridge fails to visualize a given error trace and the developer needs to find it out somewhere in a Core working directory. But I guess that it isn't very necessary (I didn't remember the case when I needed this).
Updated by Vladimir Gratinskiy almost 7 years ago
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Vadim Mutilin wrote:
We need to have a permanent ("pretty") URL for error traces which will not be changed during downloading/uploading job archives.
I think that for that purpose we can use launch names (identifiers) provided by the users (seems that we need to enforce uniqueness of them)What does "launch names" mean? Identifiers of jobs? I didn't know that users can provide jobs identifiers.
I fixed the issue description. It's about job names. And it does have sense to make them unique globally, but this is responsibility of an user.
and a error trace number relative to the given job (it should be kept during downloading/uploading job archives).
It can't be kept. I will use identifers specified in error trace json file (comments for "error traces" in https://docs.google.com/document/d/1tLOsqCQxMRlDvSNXFmaGOSQqIL8PORNI-BEsfZP8hoQ/edit). So the link will be like "/reports/unsafe/<32-bit error trace identifer>".
I don't understand why this is necessary for the specified issue. Indeed Bridge can generate and use such the identifiers itself since they are required just for permanent and unique identification of error traces within various instances of Bridge (databases). Perhaps your approach can be helpful for debugging, e.g. when Bridge fails to visualize a given error trace and the developer needs to find it out somewhere in a Core working directory. But I guess that it isn't very necessary (I didn't remember the case when I needed this).
Ok, I'll generate identifiers myself.
Updated by Evgeny Novikov over 6 years ago
- Blocked by Feature #8754: Require unique job names added
Updated by Evgeny Novikov over 6 years ago
- Target version changed from 2.0 to 1.0
Let's hurry up this issue, since it is very high demanded, so, waiting for Klever 2.0 isn't good.
Updated by Vladimir Gratinskiy over 6 years ago
- Status changed from New to Feedback
Implemented in "new-report-data".
Updated by Evgeny Novikov over 6 years ago
- Status changed from Feedback to Resolved
This seems to work at least for a single instance of Bridge.
Updated by Evgeny Novikov over 6 years ago
- Status changed from Resolved to Closed
I merged the branch to master in 4339da97 as a part of branch core-new-formats.
Updated by Evgeny Novikov about 4 years ago
- Related to Feature #10530: Improve representation of leaf reports and enhance capabilities for providing their attributes added