giseldo/neodataset huggingface dataset:
MR Review: Introduce global MR cache

### Problem to solve

When we submit a new comment on the diff, we need to calculate `newLine` and `oldLine` position. The trickiest scenario is when we comment on an unchanged line and we need to calculate the `newLine` and `oldLine` (https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/340#track-changed-lines-on-the-diff). 

We currently can't get all information we need because there is a disconnect between the data available to the `MrItemModel` and the code diff

- `MrItemModel` - we have all the API responses for MR, Discussions and MR Diff (version)
- code diff (VS Code Diff view) - we have only the URI and what we can put into `query` parameter

When we create a new comment (new `CommentThread`) the **only** information available to us is the URI.

We need access to **much more MR information** when we create a new comment.

#### URI example

```
"gl-review:/src/commands/mr_discussion_commands.ts?%7B%22commit%22%3A%2265d828eb07558c8dfe03da797f6778fc18eece8b%22%2C%22workspacePath%22%3A%22%2FUsers%2Ftomas%2Fworkspace%2Ftest-projects%2Fgitlab-vscode-extension-TEST%22%2C%22projectId%22%3A5261717%7D"
```

The cryptical `query` string is encoded JSON:

```json
{
    "commit": "65d828eb07558c8dfe03da797f6778fc18eece8b",
    "workspacePath": "/Users/tomas/workspace/test-projects/gitlab-vscode-extension-TEST",
    "projectId": 5261717
}
```

#### Why more information?

This is the full query to create a new note (notice the input):

```graphql
mutation CreateDiffNoteNonChanged {
  createDiffNote(
    input: {
      noteableId: "gid://gitlab/MergeRequest/87196674"
      body: "new note"
      position: {
        baseSha: "5e6dffa282c5129aa67cd227a0429be21bfdaf80"
        headSha: "a2616e0fea06c8b5188e4064a76d623afbf97b0c"
        startSha: "5e6dffa282c5129aa67cd227a0429be21bfdaf80"
        paths: { oldPath: "test.js", newPath: "test.ts" }
        newLine: 8
        oldLine: 8
      }
    }
  ) {
    errors
  }
}
```

We could still put most of the information into the URL. The only information that would be missing is the lines.

### Proposal

We can introduce a cache, through which we'll be able to retrieve all necessary MR information. Each MR is going to be uniquely identified by `workspaceFolder` (i.e. the local git repository) and `mergeRequest.id` the database numerical ID that is unique for GitLab instance.

The trickiest part of this cache is going to be designing the lifecycle of the cached MR (i.e. when will the cache get invalidated). Currently, we fetch all issues and MRs when the user triggers the `GitLab: Refresh Sidebar` command. (that would equal to cache invalidation).

### Further details

Sketch of how this cache could look like is implemented in the POC (#293) branch [`293-new-comments-poc`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/tree/293-new-comments-poc) (`MrRepository`)

### Links / references

Story points: 2.0
MR Review: add commenting ranges

### Problem to solve

This issue implements logic related to tracking which lines in the diff have been added/removed/unchanged. This feature needs to be behind a feature flag because we'll implement submitting new comments in a subsequent issue.

#### Commenting ranges

To be able to create new comments (not replies to a thread) we need to create a [`CommentingRangeProvider`](https://code.visualstudio.com/api/references/vscode-api#CommentingRangeProvider). We implement a function that receives a file URI and returns all the lines that the user can comment on.

Without these ranges, the user can only respond to existing comments (#339).

### Proposal

We'll need to use the textual diff that we retrieve from the [MR Diff version API endpoint](https://docs.gitlab.com/ee/api/merge_requests.html#get-a-single-mr-diff-version).

```json
{
  "old_path": "new_file.ts",
  "new_path": "new_file.ts",
  "a_mode": "0",
  "b_mode": "100644",
  "new_file": true,
  "renamed_file": false,
  "deleted_file": false,
  "diff": "@@ -0,0 +1,3 @@\n+export class NewFile{\n+    private property: string;\n+}\n"
}
```

We'll have to praise the `diff` property to find all changed lines.

### Further details

There is a follow up issue that might have to build on the logic implemented here: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/344

Example:

| no ranges | with ranges |
| ------ | ------ |
| ![gitlab_comment_thread_test_ts___197____gitlab-vscode-extension](/uploads/68d82d72b633a1cd187b1dbbb1973363/gitlab_comment_thread_test_ts___197____gitlab-vscode-extension.png) | ![_Extension_Development_Host__-_gitlab_comment_thread_test_ts___197____gitlab-vscode-extension-TEST](/uploads/f64380715c20a6a230e17dd8c95f00ce/_Extension_Development_Host__-_gitlab_comment_thread_test_ts___197____gitlab-vscode-extension-TEST.png) |

### Links / references

Story points: 2.0
MR Review: Respond to a diff thread



### Problem to solve

The extension shows us comment threads on the diff, but doesn't allow us to comment in the thread. This issue is to enable and implement responses to diff threads.

![index_md___56749____gitlab](/uploads/14cdcc1b9d790da59ddc3bb36e119c3b/index_md___56749____gitlab.png)

### Proposal

1. [Enable responses](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/d1d744624080dea35d6a5d61b28239aafb67747a/src/review/gitlab_comment_thread.ts#L50)
1. Extend the [`createNote` method](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/d1d744624080dea35d6a5d61b28239aafb67747a/src/gitlab/gitlab_new_service.ts#L532-538) to return notes (with positions), instead of `void`
1. Implement `reply()` function on the [`gitlab_comment_thread`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/d1d744624080dea35d6a5d61b28239aafb67747a/src/review/gitlab_comment_thread.ts)
1. Add a `Create comment now` command and add it to the [`comments/commentThread/context` menu](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/e09ab184e876b79f7648865c4e18272ec1802a98/package.json#L240)

### Further details

Example:

![respond-example](/uploads/7c71d116f0d4f48e286e1d418694e1d2/respond-example.mp4)

This feature is implemented (not production-ready at all) in the POC (#293) branch [`293-new-comments-poc`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/tree/293-new-comments-poc)

### Links / references

Story points: 2.0
MR Review: Resolve discussion, Edit and Delete comment

### Problem to solve

Currently, users can only view comments on MRs. If they want to interact with these comments, they'll have to switch to the web interface.

### Proposal

Implement resolving discussions, editing and deleting comments as described in detail in #269.

#### Resolving/unresolving discussions

![poc-resolve-thread](/uploads/50243d6f171f20f3f2e26e033cf2b5db/poc-resolve-thread.gif)

#### Edit comment

![poc-editing-comments](/uploads/7b16d501872a1734ab58d9e3fec50b2e/poc-editing-comments.gif)

#### Delete comment

![delete-confirmation](/uploads/5eb7158f06c0361e45141c6f2f31c232/delete-confirmation.gif)

#### Stretch: Open the comment in the browser

![poc-comment-on-the-web](/uploads/0d9652783c487deefc61ed2c1727e98a/poc-comment-on-the-web.gif)

### Further details

The ["POC Result" section of the POC issue](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/269#poc-result) provides a detailed technical description of the features
### Links / references

Story points: 3.0
Deprecate custom query with pipeline id

### Problem to solve

Custom queries are used in the sidebar view (e.g. showing "MRs assigned to me"). Custom query is a VS Code configuration object.

One of the custom query properties is `pipelineId` and it's defined as follows:

```json
{
  "pipelineId": {
    "type": "number | string",
    "description": "Returns vulnerabilities belonging to specified pipeline. \"branch\" returns vulnerabilities belonging to latest pipeline of the current branch. Works only with vulnerabilities"
  }
}
```

The `branch` part has been broken for at least 3 months, probably more (I found that when working on https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/174).

And I don't see users hardcoding a numeric `pipelineId` into their VS Code config.


### Proposal

Remove this option altogether.

### Further details


### Links / references

Story points: 1.0
Error loading Merge Requests -  "Cannot read property 'startsWith' of null"

<!---
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 -->
When trying to load MRs from a private GitLab I'm getting the error "Cannot read property 'startsWith' of null".
However, I can see issues for example.

### Steps to reproduce

<!-- How one can reproduce the issue - this is very important -->
I'm not sure but all I've done is install the extension, connect it to a privat gitlab (where we use SSH for connection), set the Personal Access Token, and add the instanceUrl, remoteName and pipelineGitRemoteName as it is reached via SSH and there is a known issue with that. (https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/79#note_495879565)


### What is the current *bug* behavior?

<!-- What actually happens -->
I was able to see MRs at first after setting the Extension up. However, I had to set "gitlab.instanceUrl"
, "gitlab.remoteName" and "gitlab.pipelineGitRemoteName" for it to work.
The next time I wanted to see a MR it didn't work giving me the error from the title with the following behavior:
When selecting "Issues assigned to me" in the extension tab, I can see the expected issues, when I select "Merge requests assigned to me" or "All project merge requests" I get the "Cannot read property 'startsWith' of null" error and I don't see any MRs.



### What is the expected *correct* behavior?

<!-- What you should see instead -->
I should be able to see MRs assigned to me or all MRs depending on which tab I'm opening.

### Relevant logs and/or screenshots

<!-- Logs can be found by running `GitLab: Show extension logs` command (using `cmd+shift+p`) -->
I'm only getting the VS Code "Cannot read property 'startsWith' of null" Error without any further information.

### Possible fixes

<!-- If you can, link to the line of code that might be responsible for the problem -->

Story points: 1.0
Fetching issue/merge request description not working in VS Code Insiders

### Summary

Fetching the issue/merge request description has stopped working in the last few weeks.

### Steps to reproduce

1. Open *GitLab Workflow* sidebar.
1. Expand a dropdown to reveal an issue or merge request.
1. Expand the issue or merge request options.
1. Click "Description".
1. Observe a new editor launch saying that it's "Fetching issuable details and discussions. This may take a while."
1. Observe that the editor never populates with the issuable details and discussions.

### What is the current *bug* behavior?

Description editor never populates with details.

### What is the expected *correct* behavior?

Description editor should show issue or merge request details.

### Relevant info and screenshots

The editor simply shows this indefinitely:

![image](/uploads/12d4f6665d02745e9cb636bf6cead63d/image.png)

- I'm currently running version v3.10.0 of the *GitLab Workflow* extension, but I believe this issue started happening a few releases prior.
- In previous versions, I was able to switch to a different editor tab and then switch back to the *Description* tab and the issue/merge request details would then populate.

### VSCode version information

- Version: 1.53.0-insider (user setup)
- Commit: 4f2341834e646360e603953b62bf6c6020b07a29
- Date: 2021-01-22T08:57:22.447Z
- Electron: 11.2.0
- Chrome: 87.0.4280.141
- Node.js: 12.18.3
- V8: 8.7.220.31-electron.0
- OS: Windows_NT x64 10.0.16299

Story points: 1.0
MR Review: Relative links in comments don't work.

### Summary

When we receive comments from the Graph QL endpoint, they might contain relative URLs. VS Code needs to have access to full URLs. For example

This comment https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/156#note_482777098

contains link

```md
![_Extension_Development_Host__-_gitlab_new_service_ts___gitlab-vscode-extension-TEST](/uploads/a262ea24dc5da36de0fb49aca7622881/_Extension_Development_Host__-_gitlab_new_service_ts___gitlab-vscode-extension-TEST.png)
```

and in VS Code it looks like:

![current_branch_js___156____gitlab-vscode-extension](/uploads/0db5eb29c8c7437a664fb2ca268b3b14/current_branch_js___156____gitlab-vscode-extension.png)

### Steps to reproduce

Open https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/156#note_482777098 in VS Code. You can find the MR by adding this [custom query](https://gitlab.com/gitlab-org/gitlab-vscode-extension#custom-queries) to you VS Code `settings.json`.

```json
    {
      "name": "Merged MRs assigned to viktomas",
      "type": "merge_requests",
      "noItemText": "There is no issue assigned to viktomas.",
      "state": "merged",
      "assignee": "viktomas"
    },
```

### What is the current *bug* behavior?

VS Code displays links and images incorrectly.

### What is the expected *correct* behavior?

The extension is going to prepend the instance URL to each relative link.

Story points: 1.0
Support Multiple Accounts per GitLab Instance

### Problem to solve

As a Freelancer, I want to be able to set the GitLab Personal Token per Git Repository / Project, so I can work with different accounts on GitLab.com

### Proposal

In general within Git it's possible to specify Identity Files specifying which ssh key to use. These can referenced per repo in the repos git config so I'm able to use different ssh keys for the same host.

It would be great to have a similar functionality for the Gitlab Workflow Extension, so it's possible to set e.g. a Company and Private Accounts Secret Token for gitlab.com

### Links / references

Story points: 2.0
Add MR's I'm Reviewing to Sidebar Lists

## Problem to Solve

[Merge Request Reviewers](https://gitlab.com/groups/gitlab-org/-/epics/5072) was added to GitLab. This allows people to be placed in the `Reviewers` role for Merge Requests. If you're a `Reviewer` those items won't be surfaced in VS Code.

## Proposal

We should add a `Merge Requests I'm Reviewing` filter to the sidebar in VS Code that retrieves a list of MR's where I'm listed as a Reviewer.

## Technical details

- We define default queries (that show in the sidebar) in [package.json](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/658a0c8bccc425bd046b5de4d1ef78a3fb7f2250/package.json#L483-489)
- The `CustomQuery` type is defined in [`custom_query.ts`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/a2b3f881f8de9c30bce5e423b51506a9935d6188/src%2Fgitlab%2Fcustom_query.ts#L2-3)
- Same way as we use [`assignee_username`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/a2b3f881f8de9c30bce5e423b51506a9935d6188/src%2Fgitlab_service.ts#L298) we would want to use `reviewer_username`.

## Possible improvements to the existing code

- Use [`URLSearchParams`](https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams) or similar method to replace the current `queryString += '&key=value'` mutations that the  `gitlab_service.ts`.`fetchIssuables()` method uses.
- Increase the test coverage for the same `fetchIssuables()` method.
  - There are a few happy path integration test scenarios in `test/integration/tree_view.test.js`
  - We could potentially introduce a Jest uni test because there is a lot of logic branching in the method.

Story points: 2.0
Use windows CI runner to run integration tests

### Problem to solve

At GitLab, using Windows for development is [strictly prohibited](https://about.gitlab.com/handbook/business-ops/team-member-enablement/onboarding-access-requests/#laptop-configurations). The extension is heavily working with the host machine file system. But the extension is rarely (if ever) tested on non-POSIX system before the release.

In some cases, this development process results in bugs (e.g. #284) that could be caught by running the integration tests on Windows.


### Proposal

Dog feed our [shared Windows runners](https://about.gitlab.com/blog/2020/01/21/windows-shared-runner-beta/).

### Further details

We would introduce another CI task similar to the `test-integration` but run by a windows CI runner.

```yaml
test-integration:
  stage: test
  variables:
    DISPLAY: ':99.0'
  script:
    - apt-get update
    - apt-get install -y xvfb libxtst6 libnss3 libgtk-3-0 libxss1 libasound2 libsecret-1-0 git
    - npm ci
    - echo $DISPLAY
    - /usr/bin/Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
    - npm run test-integration
```

### Links / references

Story points: 2.0
Use welcome view when the extension can't show TreeView

### Problem to solve

There are several scenarios when the extension can't do any useful work:

- New VS Code window (no workspace is open)
- None of the open workspaces contains a configured GitLab project
- The personal access token hasn't been set up
- There workspace folder doesn't have initialized git repository #321

For example, attempt to use the extension when there is no open project now results in an error message:

![image](/uploads/18b16f548b566c4e715efec3cc205bfb/image.png)

### Proposal

Utilise the [Welcome view](https://code.visualstudio.com/api/references/contribution-points#contributes.viewsWelcome) available in for VS Code extensions:

![poc-welcome](/uploads/e7eb40ec6996d372afa767cb7ae902b5/poc-welcome.gif)

#### Scenario 1: No token

```txt
Hey. Welcome to the GitLab Workflow extension. It seems that you have not yet set up your access token.
If you use GitLab.com, click [here](https://gitlab.com/profile/personal_access_tokens). If you have a self-managed GitLab, then: 
1. Go to 'Settings'
2. Click 'Access Tokens' on the left navigation menu
3. Click on 'Add a personal access token'
Now you can set your token by clicking on the following button
[Set Personal Access Token](command:gl.setToken)
To learn more, please [read our docs](https://gitlab.com/gitlab-org/gitlab-vscode-extension#setup).
```

- [ ] mention that the token needs `read_user` and `api` scopes to fix https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/230

**Once this scenario is implemented, we should not show the "add token" info message during every extension startup. It was bothering users: #279**

#### Scenario 2: No GitLab project

```txt
It seems like your current workspace doesn't contain a GitLab project (or the project has been moved).
```

#### Scenario 3: No open project

```txt
In order to use the GitLab Worfklow extension, please open a folder containing a GitLab project.
[Open GitLab project folder](command:vscode.open)
```

### Further details

There is a small POC implemented in [`welcome-poc` branch](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/compare/main...welcome-poc).

### Examples

| extension | screenshot |
| ------ | ------ |
| source control (no open workspace) | ![Welcome](/uploads/676ed2698d424024945391d4e342834c/Welcome.png) |
| source control (no git repository) | ![Welcome___Music](/uploads/a9d6fd9928ba19e51e4038a14621d256/Welcome___Music.png) |
| debugger | ![Welcome___Music](/uploads/36ca0ffadab097b21ae3b32bf09f12be/Welcome___Music.png) |

Story points: 2.0
Unpubished Branch on Remote generates Error

When a branch exists locally, but has not been published to GitLab there is an error in the logs:

```
Command failed with exit code 1: git config --get branch.phikai-code-review-dec-pi-update.merge
Error: Command failed with exit code 1: git config --get branch.phikai-code-review-dec-pi-update.merge
	at makeError (/Users/phikai/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.6.2/node_modules/execa/lib/error.js:59:11)
	at handlePromise (/Users/phikai/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.6.2/node_modules/execa/index.js:114:26)
	at runMicrotasks (<anonymous>)
	at processTicksAndRejections (internal/process/task_queues.js:94:5)
```

Story points: 1.0
MR Review: Show change type for each changed file

### Problem to solve

This is a follow-up to #263. Currently, we are indicating the type of git change by prepending `[added]`, `[deleted]`, `[renamed]` to the item description.

![_Extension_Development_Host__-_Welcome___gitlab-vscode-extension-TEST](/uploads/79eaf122b3480c71793ca31084ef6c52/_Extension_Development_Host__-_Welcome___gitlab-vscode-extension-TEST.png)

But once the `FileDecoration`s are [generally available in the next VS Code release](https://github.com/microsoft/vscode/issues/54938), we should use them instead:

![mr_item_ts___gitlab-vscode-extension](/uploads/a362e564c6ef5b289aa0194cbc729e35/mr_item_ts___gitlab-vscode-extension.png)

### Proposal

Implement the `FileDecorationProvider` once at least 90% of the users are on the latest version (`^1.52.0`).

### Further details

I looked into the logs today (2020-12-02) and I saw that roughly 90% of extension requests on `gitlab.com` are made by the latest VS Code version. [Today is 21 days since the latest VS Code version has been released](https://github.com/microsoft/vscode/releases/tag/1.51.1).

These numbers can be checked in the logs https://log.gprd.gitlab.net/ (only GitLab team members).

- index: `pubsub-workhorse-inf-gprd-*`
- query: `json.user_agent : "vs-code-gitlab-workflow/3.6.2 VSCode/"` AND NOT `json.user_agent : "vs-code-gitlab-workflow/3.6.2 VSCode/1.51.1"` (replace versions by the latest)

### Links / references

Story points: 1.0