QA (public) » openQA Project (public)

you can't really do that - no matter how you do it, the needles don't make sense out of the context that main.pm sets.

But what you can do is doing analysis based on the tags used. Show the needles created since the failure as information - and filter it by the tags used in the details.

@mkittler: please update. Can you work on this? If not, unassign.

@coolo Not sure whether I understand your 'get concrete' points exactly. My ideas so far I understand:

When the webui commits a needle, it should also store the needle's tags and the date of the last update internally.

This could be done by extending the database table for needles. It would be two new columns:

• Tags: A comma-separated list is likely good enough for this (instead of having an extra table for the tags).
• Last update: eg. via the usual __PACKAGE__->add_timestamps;

When opening the needle editor, the webui can then check whether a new needle with the same tags has already been created since the job has been started. In this case it shows a warning pointing to the already created needle.

I reviewed this ticket now after talking to you today: I think all needles that are relevant need to show up as candidates in the needle editor and be available to look at as well. Just mentioning them by name will not help much because a user of the needle editor will need to see the needle images at least.

Ok - the mentioned WIP PR already covers showing the needles in the 'Needle based on' selection. I've just tested it and it works.

So far it will list any needle which has been created since the job was started and contains at least one relevant tag.

I'm wondering whether the check for failure is actually necessary. Why not showing new needles always, also when opening the needle editor from a match? It would be more consistent.