Optimized LLVMFailGitHubReporter and added LLVMFailGitHubLabeler

[slydiman]

• Added LLVMFailGitHubLabeler
• Added LLVMLabelFormatter
• Added LLVMFailBuildGenerator.is_message_needed_custom
• Added the config for labeling backend:nvptx
• Used GitHubStatusPush.debug flag for the debug purpose (simulate mode)
• Moved the issue # checking to is_wrong_issue()

[vvereschaka]

Hi @slydiman ,

would you please put here a description how do we detect the cases? I.e. is_message_needed_nvptx_backend() there.

As far as I understood the function checks only the result of the 6-th build step, which is build-unified-tree currently, to decide a necessary of marking an appropriate github issue. What if the build step position will be changed in future? Is it possible to do more precise check there?
Also, I suppose is is necessary to check the llvm-check step for the build. We can get the failed nvptx tests there and mark the issue in that case.

[vvereschaka]

Also, probably you already though about it, but what could be bad in idea with creating a new class based on utils.LLVMFailBuildGenerator and override proper functions like is_message_needed_by_results / generate and so on? That will completely split the common and the nvptx specific parts and eliminate extra arguments such as is_message_needed_custom.

[slydiman]

would you please put here a description how do we detect the cases?

Actually, I don't know the final list of conditions. I did not receive any feedback with details on the draft. So I created this PR.
Any condition details and ideas are welcome.

[slydiman]

Also, probably you already though about it, but what could be bad in idea with creating a new class based on utils.LLVMFailBuildGenerator and override proper functions like is_message_needed_by_results / generate and so on? That will completely split the common and the nvptx specific parts and eliminate extra arguments such as is_message_needed_custom.

I don't like an idea to create a custom class for each specific case. I tried to create an universal class. The handler is_message_needed_nvptx_backend may be moved to the config file.

[vvereschaka]

would you please put here a description how do we detect the cases?

Actually, I don't know the final list of conditions. I did not receive any feedback with details on the draft. So I created this PR. Any condition details and ideas are welcome.

Is it possible to get a link to the draft? Or put here?

[vvereschaka]

Also, probably you already though about it, but what could be bad in idea with creating a new class based on utils.LLVMFailBuildGenerator and override proper functions like is_message_needed_by_results / generate and so on? That will completely split the common and the nvptx specific parts and eliminate extra arguments such as is_message_needed_custom.

I don't like an idea to create a custom class for each specific case. I tried to create an universal class.

but you like creating the custom functions :).

The handler is_message_needed_nvptx_backend may be moved to the config file.
Hm... hm. Bad idea I think.