giseldo/neodataset huggingface dataset:
Multi-root workspace with a non-GitLab project doesn't work: Error: 404 Project Not Found

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=bug

and verify the issue you're about to submit isn't a duplicate.

If you are facing issues around configuring Token from your GitLab.com account, see the list of already addressed Token related issues:

https://gitlab.com/gitlab-org/gitlab-vscode-extension/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=token-issue
--->

### Summary

<!-- Summarize the bug encountered concisely -->

Ext is going to be useless if project could not be fetched by API.

### Steps to reproduce

<!-- How one can reproduce the issue - this is very important -->

1. Clone [gitlabhq/terraform-provider-gitlab](https://github.com/gitlabhq/terraform-provider-gitlab) from GitHub to folder on the workstation.
2. Clone [gitlab-org/gitlab-vscode-extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension) from GitLan to folder on the workstation.
3. Add both repos to VS Code and save workspace configuration.
4. Go to GitLab sidebar.
5. Click on **refresh** icon.
6. Gitlab Extension fails with error notification.


Clone git repo with valid git remote url.
Change git remote url to something else.
Go to sidebar and refresh your issues / merge requests.

### What is the current *bug* behavior?

<!-- What actually happens -->

GitLab Ext tries to fetch project info by given group name extracted from git remote url, and fails when project could not found.
API request failed when trying to get current project because: 404 - "{\"message\":\"404 Project Not Found\"}"

### What is the expected *correct* behavior?

<!-- What you should see instead -->

Ext shouldn't fail in case if project does not exist by given group name, or added git repo is originally from Github, Bitbucket, etc.

### Relevant logs and/or screenshots

![image](/uploads/ddb7df56f55eed8cd30667e17c98323f/image.png)
![image](/uploads/86b9bcd45c9b0b5c8bcc195838b59559/image.png)

<!-- Logs can be found by running `GitLab: Show extension logs` command (using `cmd+shift+p`) -->

### Possible fixes

<!-- If you can, link to the line of code that might be responsible for the problem -->

Story points: 1.0
Add the ability to show pipelines within vscode

### Problem to solve

Currently, it's necessary to open the pipeline in the GitLab web interface to learn details about jobs.

We show some rudimentary pipeline information in two places:

|  |  |
| ------ | ------ |
| status bar | ![current_branch_ts___gitlab-vscode-extension](/uploads/62d29acd8ec085d24ffdf8ed9f320ab5/current_branch_ts___gitlab-vscode-extension.png) |
| "For current branch" sidebar | ![current_branch_ts___gitlab-vscode-extension](/uploads/b5c0a3a2f2b7e63b7b5210bed72a8190/current_branch_ts___gitlab-vscode-extension.png) |

### Proposal

Extend the tree item in the sidebar to show information about all jobs:

| before | after |
| ------ | ------ |
| ![current_branch_ts___gitlab-vscode-extension](/uploads/efb1e59d5061b4a87146af8e3dba4bd9/current_branch_ts___gitlab-vscode-extension.png) | ![_Extension_Development_Host__-_README_md___test-project](/uploads/e9b76e1e5f5ff1a23694b307ee7d7c22/_Extension_Development_Host__-_README_md___test-project.png) |

### Further details

The API information is available and it should be fairly simple to render the UI as shown above.

This work would provide basis for:

- starting/stopping/retrying jobs #97 
- seeing job logs #423 
- downloading job artifacts #106

The auto-update would be a great follow-up [Auto update "For Current Branch" tab in sidebar](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/60)

<details>
<summary>Original description</summary>

Possible duplicate: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/97

### Problem to solve

It's very convenient having the ability to create, view, and comment on issues from within vscode. 

I understand there are a few open issues related to pipelines jobs that I'd assume would be tied into this solution. But I didn't see an open issue specifically requesting this feature, although https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/97 may actually be good enough honestly, if it would work like issues/MRs do.


### Proposal

Curious if embedding `/-/pipelines/$Pipeline_ID` would be an option, similar to what the experience is when clicking an issue and how we can "View issue and MR details and comments in VS Code"? This would at least allow us to see which job failed, if nothing else. 

### Further details

It looks like @fatihacet did some work towards integrating jobs under pipelines in For Current Branch section of the sidebar and that's great!...not sure if that work/code transferred over with the project ownership shift. I'm not sure if the intent was clicking one of those jobs would have opened the build output?...that's what I would love to see!

### Links / references


</details>

Story points: 2.0
MR Review: Show comments on changed file diff

### Problem to solve

Users who perform MR review in VS Code can get additional context from commetns that are placed directly on the diff.

### Proposal

![_Extension_Development_Host__-_test_js__MR____test-project](/uploads/53a54bf961c2845edf5d527771348e5a/_Extension_Development_Host__-_test_js__MR____test-project.png)

We are going to fetch all comments for the MR and show the non-outdated on the diff.

### Further details

This issue is described in a detail on the POC work here: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/243#showing-existing-comments

### Out of scope

- adding, editing or deleting comments
- reactions

### Links / references

Story points: 2.0
MR Review: Show changed file diff (Git-provided)

### Problem to solve

After implementing https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/264, user can see change diff for an MR file, but the change needs to be fetched from the GitLab API, putting additional load on the API but mainly decreasing the responsivness of the review. Often the file is going to be already present in the local Git repo and that's where we'll try to get it from.

### Proposal

Implement a content provider that will be able to serve file content for a specific version. It will serve this content from the local git repository.

### Further details

Showing the diff is explained in the [MR Review POC](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/243#file-diff-view). When we are done, we'll have a chain of content providers as shown in:

```mermaid
graph LR
A[VS Code] -- "gl-review: URI" --> B[LocalGitContentProvider]
B --> C[RemoteApiContentProvider]
```

This issue implements the `LocalGitContentProvider`

Good way to approach this is going to be to use the native Git extension that is always present as a part of VS Code. That way we'll have all git-related information in VS Code in sync. Eventually we might want to move away from executing the git command ourselves in other parts of the codebase as well.

### Links / references

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/243

Story points: 3.0
MR Review: Show changed file diff (API-provided)

### Problem to solve

When reviewing MRs, users need to see changed files. This is going to be the first iteration of showing users the changes made in the file.

### Proposal

![Extension\_Development\_Host\_-\_terraform\_list\_vue\_\_MR\_\_\_\_gitlab\_and\_Add\_\_Ability\_to\_chec\_\_\_\_\_\_gitlab-vscode-extension\_and\_zsh](https://gitlab.com/gitlab-org/gitlab-vscode-extension/uploads/8731b1c3adb85de00977d0a4edbfdeb5/_Extension_Development_Host__-_terraform_list_vue__MR____gitlab_and_Add__Ability_to_chec______gitlab-vscode-extension_and_zsh.png)

Once the user clicks on a changed file (see https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/263), VS Code will open a file diff showing the change. VS Code will get file content from the GitLab instance API.

### Further details

Showing the diff is explained in the [MR Review POC](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/243#file-diff-view). When we are done, we'll have a chain of content providers as shown in:


```mermaid
graph LR
A[VS Code] -- "gl-review: URI" --> B[LocalGitContentProvider]
B --> C[RemoteApiContentProvider]
```

This issue is going to implement the remote content provider. We'll start with the remote provider in the first iteration because the remote provider will always have the content and the local git provider is optimisation that we'll implement next.

Showing diff for images and other binaries is out of scope.

We need to have a look into how to show diffs of extra large text files like `package-lock.json`.

### Links / references

Story points: 2.0
MR Review: Show changed files for the MR

### Problem to solve

As a part of MR review, users need to see what files changed. It's the initial step in selecting a chagned file and inspecting the MR diff view.

### Proposal

![_Extension_Development_Host__-_agents_spec_js___gitlab](/uploads/411e83788322641d0258bdf50b2ad547/_Extension_Development_Host__-_agents_spec_js___gitlab.png)

Building on top of the work in https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/243 we would extend the MR items in the tree view as per the screenshot. For each MR user can click on the MR and see an item representing the description and all changed files.

### Further details

- We would have a chance to deside what icons do we want to show and we could also redesign the tree structure (e.g. grouping issue queries and MR queries)
- The current implementation of the tree view is mainly untested (except for a few integration tests) and it is not extensible in its current form. We will need to refactor the tree view a bit before we can start building on top of it.


### Links / references

Story points: 2.0
Consistent handling of remotes, instances and branches

### Problem to solve

With the implementation of https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/90 we started discovering several classes of errors related to parsing information about the workspace git repository.

The main issue is the complex edge cases that were never considered (sorted by how frequently they occur):

- Mutiple remotes in one repository
  - here we can get a remote that is not matching the defined `instanceUrl` (more details: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/115#note_410341027)
- Multi-root workspaces
  - Which remote, `instanceUrl` and branch to use when there are multiple git repositories in one workspace?
  - currently, we use the open file to find out what git repository should we use, but if there's no file open we have very inconsistent handling
- Tracking branches
  - sometimes we ask for [tracking branch](https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches#_tracking_branches) which can again point to a different remote than what we use for rest of the requests

### Proposal

Separate the current `GitService` into three modules with different responsibilities:

- thin layer on top of the `git` shell command
- instanceUrl service that would be responsible for matching git remotes and define tokens
- GitLab-specific git logic (e.g. picking which remote to use based on an instanceUrl, creating GitLab API URL based on git remote)

The last service would return an object with the following attributes:

- `apiUrl` - where to send API requests
- `namespace` - group or username
- `project` - project name
- `branch` (optional) - remote branch (e.g. to query for active pipelines)


### Further details

The main benefit of the proposed solution is that we would have certainty that our `instanceUrl` matches the `namespace`, `project`, and `branch` information. This would reduce hard to remove issues and it would improve the environment for contributors because the current edge-case ridden code is very hard to understand.

We also have two config options that override the aforementioned logic:

```json
"gitlab.remoteName": {
  "type": "string",
  "default": null,
  "description": "Name of the git remote to use in order to locate the Gitlab project"
},
"gitlab.pipelineGitRemoteName": {
  "type": "string",
  "default": null,
  "description": "Name of the git remote to use in order to locate the Gitlab project for your pipeline. Keep empty for default"
},
```

### Links / references

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/34
- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/71

Story points: 3.0
Collecting MAU for GitLab Workflow (VS Code) Extension

## Problem to Solve

The GitLab Workflow Extension is currently used outside of the main GitLab application and connects to GitLab instances via API to perform tasks. There is currently no standard way within GitLab to understand this usage and provide accurate usage statistics to aid in feature development, prioritization and continued investment in the extension.

## Additional Details

GitLab has a series of [performance indicators](https://about.gitlab.com/handbook/product/performance-indicators/#structure) based around AMU (Active Monthly Users). In many cases these are measured as aggregate counts of users who engage with certain features over a period of time. An example of this is for the ~"group::editor" [`Git write operations from web editors`](https://about.gitlab.com/handbook/product/dev-section-performance-indicators/#createeditor---gmau---mau-conducting-git-write-operations-from-web-editors) are measured.

## Proposal

Intercept some hook for all API calls or develop/use a rack middleware. This way we could log usage in Redis using Product Analytics HLL (distinct counts) or regular count APIs.

<details><summary>Old Proposal</summary>

### Option 1

With the release of GitLab Workflow 3.6.0 a [User-Agent is included in all API requests](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/238) that identifies the extension and the version. If log collection and importing of specific data was available in the Data Warehouse ([other](https://gitlab.com/gitlab-data/analytics/-/issues/5305) [proposals](https://gitlab.com/gitlab-data/analytics/-/issues/5200) suggesting log usage) we could aggregate logs based on this user agent. We would need some way to get additional data to identify users in aggregate and not specifically, but this could be a foundation for getting usage numbers.

### Option 2

In an effort to [improve the onboarding flow](https://gitlab.com/groups/gitlab-org/-/epics/4363) a proposal is being considered to [implement OAuth](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/221) for using the extension. OAuth applications are [stored in the database](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/structure.sql#L13981) of GitLab which would allow us to count the number of authorizations. **Lacking from this could be last used as that doesn't appear to be tracked.**

Also important is that the level of effort required for Option 2 might be [quite significant](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/221#note_438407317) and is not the preferred path at this time.

</details>

Story points: 3.0
Can't respond in comment thread in webview for MR/Issue

## Problem to solve

Inside of Issues and Merge Requests you can comment in a new comment or via a threaded reply to a parent comment. The option to reply in a thread to a parent comment is not available inside of the webview for issues/merge requests.

![Screen_Shot_2020-10-22_at_12.13.09_PM](/uploads/6b7d158f17d3e5222e38ecc06f18c0be/Screen_Shot_2020-10-22_at_12.13.09_PM.png)

## Proposal

The ability to respond via a threaded reply should be added so that conversations can be properly tracked and resolved.

Story points: 2.0
Include User-Agent to all API requests

### Problem to solve

We don't know how many of our users are using the extension and we managed to push some extension changes in the past that started hitting GitLab.com API hard (https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/211)

### Proposal

Include [User-Agent header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent) to all API requests made by the extension. This way we'll be able to see how many requests are coming from the extension.

```User-Agent: vs-code-gitlab-workflow/${packageJson.version}```

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->

### Links / references

For GitLab team members, the access logs can be seen in https://log.gprd.gitlab.net/app/kibana

Story points: 1.0
Detached Pipeline Status

### Problem to solve
As a developer in a company that uses only [Pipelines for Merge Requests](https://docs.gitlab.com/ee/ci/merge_request_pipelines/), I would still like to be able to see the status of my current pipeline in VSCode. Currently, it always reports "No pipeline found", because there is no pipeline associated with the branch. Only with the Merge Request.


### Proposal
If a related merge request is detected, try fetching the status of the Merge Request Pipeline first, and if that does not exist fall back to fetching the pipeline for the branch.

Maybe add a config option to toggle this behavior on/off

### Further details
n/a

### Links / references

- [REST API docs](https://docs.gitlab.com/ee/api/merge_requests.html#list-mr-pipelines)

Story points: 2.0
Improve onboarding by enabling users to get started via OAuth

### Problem to solve
Right now a user has to set his personal access token (PAT) to login to the GitLab instance. So the user needs to go to the instance, go through the settings, grab the token, go back to VSCode and paste the token and hopefully it works. This works but the workflow could be much better here.

### Proposal
After trigger the GitLab login command in VSCode
1. the user get asked for the GitLab instance url
2. the browser popup with a tab with the "authorize" application for ... 
3. user get some kind of popup that login was successful

This would make it also easier to setup multiple GitLab instances.

### Links / references

- Documentation [GitLab as an OAuth2 provider](https://docs.gitlab.com/ee/api/oauth2.html#gitlab-as-an-oauth2-provider)
- [Discussion: Streamlined GitHub authentication · Issue #93 · microsoft/vscode-pull-request-github](https://github.com/microsoft/vscode-pull-request-github/issues/93)

#### Example of GitHub extension authentication

![Kapture_2020-08-04_at_13.50.59](/uploads/d5b71ee72819ca6748fc6a74a5215c97/Kapture_2020-08-04_at_13.50.59.gif)

Story points: 2.0
TS migration 2: migrate gitlab_service

### Problem to solve

This is a followup issue for #219. `gitlab_service.js` has got 670 LOC and because we need to convert a JS file to TS in one go, we are creating a separate issue just for this conversion. The rest of the extension will be converted in the spirit "you touch it, you convert it".

### Proposal

We are going to migrate the `gitlab_servic.js` to TypeScript. This service is providing the rest of the extension with information from the GitLab instance.

```mermaid
graph TD
A[rest of the extension] --> B
D[status_bar] -->
B[gitlab_service] -->
C[git_service.ts]
B --> D
```

### Further details

#### In scope

- break the cyclic dependency so that `gitlab_service` isn't dependent on `status_bar`
- write 3 - 5 integration tests touching the GitLab service
- define types for `token_service` and `gitlab_project_input` (or migrate them to TS if it's trivial)
- rewrite the `gitlab_service.js` to TypeScript
- manual testing afterwards

#### Out of scope

- rewriting any other code to TypeScript
- extensive test coverage with unit test (would take too long)
- redesigning the `gitlab_service.js` (for easy review, the code branches and interfaces shouldn't change too much)

### Links / references

- original decision to split the work this way: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/204#note_388292319
- example of the rewrite can be found in !53

Story points: 2.0
TS migration 1: configure TS and migrate git_service

### Problem to solve

We decided to proceed with migrating the small codebase of this extension to TypeScript #204. We are going migrate the extension iteratively. This is the first step.

### Proposal

We are going to migrate the `git_service.js` to typescript. This service is providing the extension with information about the project git repository (branches, remotes ..). The rest of the extension is dependent on this service and we can start immediately benefit from using autocomplete in code dependent on git.

```mermaid
graph TD
A[rest of the extension] -->
B[gitlab_service] -->
C[git_service]
A --> C
```

### Further details

#### In scope

- write integration tests touching the git service - namely, test functionality that uses:
    - branch name
    - tracking branch name
    - current commit SHA
    - remote repository URL
- configure TypeScript compilation in a way that it works with the rest of the extension which is still in JavaScript
- configure TypeScript linting and prettier
- rewrite the `git_service.js` to TypeScript
- introduce static `create()` method as described in https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/100#note_414925480
- manual testing afterwards

#### Out of scope

- rewriting any other code to TypeScript
- extensive test coverage with unit test (would take too long)
- redesigning the `git_service.js` (for easy review, the code branches and interfaces shouldn't change too much)

### Links / references

- original decision to split the work this way: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/204#note_388292319
- example of the TS configuration and rewrite can be found in !53

Story points: 3.0
webview: extension sometimes posts same comment multiple times

### Summary

Sometimes the extension sends the same entered message multiple times to the opened issue/MR when using the experimental webview.

### Steps to reproduce

Note that in my experience this seems to be inconsistent.

1. Enable Experimental Features in Extension Settings (gitlab.enableExperimentalFeatures)
1. Open an issue in webview
1. Send a comment

I should note that I have had more success getting this to happen when multiple webview-tabs are open simultaneously (I tested with two), though I had this happen even with only one webview tab open. Perhaps other tabs (like open files) also cause this or maybe doing the multiple tabs aren't strictly required for the bug to occur.

The first time I encountered this behaviour was before GitLab officially adopted this extension, so it isn't a recent development.

### What is the current *bug* behavior?

The same message is sent to the same issue multiple times instead of once. Quick actions seem to be applied multiple times, too.

### What is the expected *correct* behavior?

The new comment and any included quick action should only be added/triggered once.

### Relevant logs and/or screenshots

![GitLab_Workflow_Message_duplication_glitch](/uploads/4f0c7cd0d1fbf3a8d1feffaf3d51b78d/GitLab_Workflow_Message_duplication_glitch.gif)

### Possible fixes

No idea.

### Versions and OS
* VSCode Version: 1.47.0 (commit d5e9aa0227e057a60c82568bf31c04730dc15dcd)
* Extension Version: 3.0.4 (from official marketplace)
* OS: Arch Linux x86_64 (all packages up-to-date)

Story points: 2.0