Add workflows to use github-issues-scraper after docs-scraper on deploy

[tpayet]

This PR add the github-issues-scraper run after docs-scraper during deploy of documentation.
It adds the ability to search through GitHub issues & PR of meilisearch/meilisearch from the documentation search bar.

The worklfow is almost done but I still have an issue regarding links that are not directing to GitHub

[curquiza]

Are all the settings set up to this repo? 🙂

[tpayet]

Are all the settings set up to this repo? 🙂

Yes, I just added them!

[curquiza]

I approve but it should be a draft since we cannot merge it because of the issue I'm fixing right now.

[curquiza]

Hum, I realize I don't really like the display for the GitHub results:

All the results are the same issue, except there are different comments. But the results do not bring new useful information: there are all the same information.

We use a distinctUrl on url field. It means if 2 results have the same url, it will only display the first one. But currently, all your URLs are unique because of the comments urls that look like this:
https://github.com/meilisearch/MeiliSearch/issues/655#issuecomment-636310981

I would like your github-issues-scraper to use url only for the PR or issue url (https://github.com/meilisearch/MeiliSearch/issues/655) and the anchor for the comment (issuecomment-636310981).

I will adapt the code in this PR (for the front part) once you fixed that, if you agree with me @tpayet .

[curquiza]

Question

Are the closed PRs and issues added to MeiliSearch? 🙂

[bidoubiwa]

Where are we with this PR ?

[fharper]

Any news about this PR?

[fharper]

I approve but it should be a draft since we cannot merge it because of the issue I'm fixing right now.

I changed the status to draft based on what you wrote @curquiza

[guimachiavelli]

@meilisearch/docs-team has discussed this PR today and decided to close it. This is due to relevancy and usability reasons:

1. As @curquiza's screenshot illustrates, results currently include repeated links of the same issue;
2. We believe it can be confusing for the same search bar to possibly lead a user to two different locations (docs website and github issue) without any indication of what they're going to get once they click the search result;
3. Although the issues add extra information, that information might be distracting rather than useful.

We are looking into a different solution for this problem which would involve taking the user to github issues only if no relevant results can be found on the docs.