giseldo/neodataset huggingface dataset:
API calls fail when the GitLab instance is on a custom path, but the git remote isn't

## Summary

The API calls are not working when the `gitlab.instanceUrl` setting contains a custom path, but the `git remote` URL doesn't.

Example:

```
"gitlab.instanceUrl": "http://aom-int/gitlab",
```

and `git remote`:

```
git@aom-int:depoortere/testmaven.git
```

The parsing logic expects that if the `instanceUrl` contains a custom path, the `git remote` will too. From the example above: `http://aom-int/gitlab` `instanceUrl` should have `git@aom-int:gitlab/depoortere/testmaven.git` `git remote`.

### Details

The original issue with GitLab on a custom path is this: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/42

And the initial fix was implemented in https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/11.

[The implementation](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/56dab86117c109443a9422b85b58605fa5b774f1/src/git/git_remote_parser.ts#L30) assumes that if your GitLab instance is on a custom path (e.g. `/gitlab`) then the `git remote` URL contains the same path (i.e. in above scenario the remote should be `git@aom-int:gitlab/depoortere/testmaven.git`. I'm not sure whether that's a reasonable assumption or not, but it doesn't hold true in above scenario.

A workaround might be to use `https://` remote URL instead of the `git@..`. I assume that the `https://` version would have `/gitlab` in the remote path.

The code for parsing remotes is in [`git_remote_parser.ts`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/56dab86117c109443a9422b85b58605fa5b774f1/src/git/git_remote_parser.ts#L10-38). I'm open to suggestions about how to change it. I also include a failing test with above scenario:

<details>
<summary>Failing test case</summary>

```diff
diff --git a/src/git/git_remote_parser.test.ts b/src/git/git_remote_parser.test.ts
index 33cba5a..c3c4586 100644
--- a/src/git/git_remote_parser.test.ts
+++ b/src/git/git_remote_parser.test.ts
@@ -81,4 +81,14 @@ describe('git_remote_parser', () => {
       project: 'gitlab-vscode-extension',
     });
   });
+
+  it('should support host aliases with a custom path', () => {
+    expect(
+      parseGitRemote('git@aom-int:depoortere/testmaven.git', 'https://aom-int/gitlab'),
+    ).toEqual({
+      host: 'aom-int',
+      namespace: 'depoortere',
+      project: 'testmaven',
+    });
+  });
 });
```

</details>


<details>
<summary>Original issue description</summary>

Say my GITLAB instance URL is https://xyz.com/gitlab  (Exposed via Nginx)

In this case, the parsing by the extension is done incorrectly and fails to retrieve any information.

The parsed array gives this (removing /gitlab from the path):

["http:", "xyz.com", "my-group/subgroup1", "project"]

And thus the extension does not work. I tried concatenating the extra "/gitlab" and still it does not work.

Meanwhile, what ports does this extension need/use? I only have https port of my instance exposed - have not exposed the SSH or git port.

</details>

Story points: 1.0
Matching access token URL with GitLab instance URL is too strict

<!---
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

The GitLab instance URL configured in `gitlab.instanceUrl` and the URL you specify when adding a new access token needs to match perfectly. If one contains slash at the end, the token is not used.

<details>
<summary>Original description</summary>

Connection issues with self-hosted GitLab instance URL name.

e.g. correct connection when `https://my.gitlabinstance.io/group-name/project1` as opposed to `https://my.gitlabinstance.io/group-name/project1/`

There are no instructions that mention to put it exactly like this...

</details>

### Steps to reproduce

1. open workspace with project on `gitlab.com`
1. remove your token with `GitLab: Remove your Personal Access Token` command
1. add the same token but specify `https://gitlab.com/` as the instance URL (notice the `/` at the end)
1. now the extension can't authenticate your requests and you see an error

### What is the current *bug* behavior?

The extension cant match the token for `https://gitlab.com/` with the configured instance `https://gitlab.com` (without the slash)

### What is the expected *correct* behavior?

The extension should be able to recognise that those two URLs are for the same GitLab instance and use the token

### Relevant logs and/or screenshots

![Screenshot_2020-07-24_at_1.23.50_PM](/uploads/eacc8e0190ed9b87a0e65104e5cad0d4/Screenshot_2020-07-24_at_1.23.50_PM.png)

### Possible fixes

A naive solution would be to remove trialling slashes. A more complete solution could be parsing the URLs and deciding what parts need to match (most likely hostname, and port, maybe protocol).

Story points: 1.0
Auto update "For Current Branch" tab in sidebar

To improve the current behavior "For Current Branch" tab should auto update itself.

Also refreshing the panels should clear issue and MR cache. Related with this one https://gitlab.com/fatihacet/gitlab-vscode-extension/issues/21

## Problem

Rith now the sidebar with "For Current Branch" information needs to be manually refreshed and it will likely show outdated information.

Additionally, the status bar refreshes every 30s, but at the start of the VS Code, the first refresh happens before the extension can access the git repository and the user always sees roughly 25s of "initializing status bar":

![status bar](https://gitlab.com/gitlab-org/gitlab-vscode-extension/uploads/815e15090c1dc2566e48c75b8bcc1bc0/Screenshot_2021-09-07_at_20.10.54.png)

## Proposal

Both the "For Current Branch" sidebar panel and the status bar are using the same information (pipeline, MR, and issue). I suggest that they'll get automatically updated together. The update is going to be triggered by the following events:

- Repository has been initialized (fixes the initial 25s of delay)
- Branch has been changed
- 30 seconds have passed since the last update (only this is now partially implemented)

Story points: 2.0
Merge requests fail where branch contains a # symbol


### Summary

When we call `GitLab: Crete new merge request on current branch` command, branch with `#` doesn't get escaped causing incorrect branch name

### Steps to reproduce

1. Create `test-#-hash` branch and push a commit to the remote.
1. Run `GitLab: Crete new merge request on current branch` command

### What is the current *bug* behavior?

The branch name appears unescaped in the URL:

```
http://127.0.0.1:3000/root/empty-test-2/-/merge_requests/new?merge_request%5Bsource_branch%5D=test-#-hash
```

The `#-hash` gets treated as the browser ID fragment.

### What is the expected *correct* behavior?

The `#` is encoded and we open the MR with the following URL:

```
http://127.0.0.1:3000/root/empty-test-2/-/merge_requests/new?merge_request[source_branch]=test-%23-hash
```

### Relevant logs and/or screenshots

![Screenshot_2020-08-05_at_11.14.34_AM](/uploads/2631da4c7bea6a6e97901e44cd4ff374/Screenshot_2020-08-05_at_11.14.34_AM.png)

### Possible fixes

Probably calling `encodeURIComponent(branchName);` is enough to fix the issue.

Story points: 1.0
Add OAuth support for VSCodium

When I click the `Connect to GitLab.com with OAuth` button I get a redirect error screen on GitLab's Web UI:

![image](/uploads/9b062930e8dad00ac522e49fd6c6a30b/image.png)

This is probably due to it being on VSCodium... so the redirect url includes: `vscodium` instead of `vscode`:

```
https://gitlab.com/oauth/authorize?client_id=...&redirect_uri=vscodium%3A%2F%2Fgitlab.gitlab-workflow%2Fauthentication&response_type=code&state=...&scope=api+read_user&code_challenge=...&code_challenge_method=S256
```

we likely need to add it as valid redirects

Story points: 1.0
Don't log the whole token

<!---
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.
--->

### Checklist

<!-- Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version. -->

- [ ] I'm using the latest version of the extension ([see the latest version in the right column of this page](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow))
  - Extension version: _Put your extension version here_
- [ ] I'm using the latest VS Code version ([find the latest version here](https://github.com/microsoft/vscode/releases))
  - VS Code version: _Put your VS Code version here_
- [ ] I'm using a supported version of GitLab ([see README for the supported version](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#minimum-supported-version))
  - GitLab version: _Put your GitLab version here, or say "happens on `gitlab.com`"_

### Summary

When user enables debug logging, we log the whole token in the extension output every time the OAuth token is refreshed (~2h). Ideally we would like not to log the whole access token.

https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/77a1cbc0f7d85dbab917d8c06203663bbc87b525/src/gitlab/token_exchange_service.ts#L111

### Steps to reproduce

<!-- How one can reproduce the issue - this is very important -->

### What is the current _bug_ behavior?

<!-- What actually happens -->

### What is the expected _correct_ behavior?

<!-- What you should see instead -->

### Relevant logs and/or screenshots

<!-- Logs can be found by running `GitLab: Show extension logs` command (using `cmd+shift+p`). Please enable `"gitlab.debug": true` in your `settings.json`. Debug mode will improve error stack traces and adds debug log messages. -->

### Possible fixes

<!-- If you can, link to the line of code that might be responsible for the problem -->

Story points: 3.0
Custom Query error with `avatar_url` in Vulnerabilty Reports

## Problem to Solve

When using a custom query to look at vulnerability reports, there is an issue with `avatar_url` being expected in the response:

**Error Message:**
```
[error]: Cannot read properties of undefined (reading 'avatar_url')
         TypeError: Cannot read properties of undefined (reading 'avatar_url')
         	at /Users/phikai/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.47.2/out/extension.js:298:239
         	at Array.map (<anonymous>)
         	at Js.getIssuables (/Users/phikai/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.47.2/out/extension.js:327:3252)
         	at processTicksAndRejections (node:internal/process/task_queues:96:5)
         	at async bd.getProjectIssues (/Users/phikai/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.47.2/out/extension.js:344:2214)
         	at async bd.getChildren (/Users/phikai/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.47.2/out/extension.js:344:2963)
         	at async v.fetchChildrenNodes (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:106:19736)
         	at async v.getChildren (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:106:15955)

```

**Custom Query:**
```
"gitlab.customQueries": [
        {
        "name": "Vulnerability Reports",
        "type": "vulnerabilities",
        "scope": "all",
        "noItemText": "No Vulns.",
        "state": "opened"
        }
    ] 
```

This was tested against the `gitlab-org/gitlab` project.

Story points: 1.0
Update development documentation

### Problem to solve

The development documentation hasn't been updated in about a year. We plan to add more team members as maintainers soon. That means we need the development documentation up to date.

### Proposal

Review the following documents:

- [x] CONTRIBUTING.md
- [x] docs/developer/architecture.md
- [x] docs/developer/ci-variables.md
- [x] docs/developer/coding-guidelines.md
- [x] docs/developer/commits.md
- [x] docs/developer/developer-process.md
- [x] docs/developer/maintainer.md
- [x] docs/developer/release-process.md
- [x] docs/developer/security-releases.md
- [x] docs/developer/testing-strategy.md
- [x] docs/developer/writing-tests.md


### Links / references

Story points: 1.0
PAT no longer available after restart

<!---
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.
--->

### Checklist

<!-- Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version. -->

- [x] I'm using the latest version of the extension ([see the latest version in the right column of this page](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow))
  - Extension version: v3.44.1
- [x] I'm using the latest VS Code version ([find the latest version here](https://github.com/microsoft/vscode/releases))
  - VS Code version: 1.67.1
- [x] I'm using a supported version of GitLab ([see README for the supported version](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#minimum-supported-version))
  - GitLab version: 14.9.1

### Summary

Initial installation of the plugin works well after the PAT and URL are set up.

After shutdown of VSCode and restart the PAT seems to be unavailable.

I'm not sure how to debug any further.

### Steps to reproduce

1. Start with a linux desktop environment.  In this case Archlinux with SwayWM.
2. Launch VSCode, install the plugin, and configure it with a URL and PAT.
3. Observe all works well.
4. Exit VSCode and re-launch.
5. Observe that the extension no longer is authenticated
6. Attempt to provide the URL and a new PAT, but it never succeeds.

### What is the current _bug_ behavior?

Plugin no longer works.

### What is the expected _correct_ behavior?

1. That the PAT is retained for next launch
2. That the plugin continues to work after re-launch

### Relevant logs and/or screenshots

```
[error]: Account for instance REDACTED and user REDACTED is missing token in secret storage. Try to remove the account and add it again.
```

### Possible fixes

<!-- If you can, link to the line of code that might be responsible for the problem -->

Story points: 2.0
MR Review comments are not rendering Markdown

### Checklist

<!-- Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version. -->

- [x] I'm using the latest version of the extension ([see the latest version in the right column of this page](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow))
  - Extension version: `3.43.1`
- [x] I'm using the latest VS Code version ([find the latest version here](https://github.com/microsoft/vscode/releases))
  - VS Code version: `1.67.0-insider`
- [x] I'm using a supported version of GitLab ([see README for the supported version](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#minimum-supported-version))
  - GitLab version: "happens on `gitlab.com`"

### Summary

Markdown in MR comments stopped rendering in the newer version of VS Code

![gitlab-vscode-extension](/uploads/0096dfa1ad3ae66b41f819f5abb5e238/gitlab-vscode-extension.png)

GitLab Workflow depended on a "bug" in VS Code. VS Code rendered plain text comment body as markdown ([Comment.body rendered as Markdown, even for plain strings · Issue #140967 · microsoft/vscode](https://github.com/microsoft/vscode/issues/140967)). They fixed it in February 2022 and since then we show plain text MR comments.

### Steps to reproduce

1. See any MR comment with Markdown syntax.

### What is the current _bug_ behavior?

Markdown is shown as plain string.

### What is the expected _correct_ behavior?

Markdown should be rendered.

![_Extension_Development_Host__-_gitlab-vscode-extension-TEST](/uploads/e875bc21fe466c6210a51ff67691e998/_Extension_Development_Host__-_gitlab-vscode-extension-TEST.png)

### Relevant logs and/or screenshots

<!-- Logs can be found by running `GitLab: Show extension logs` command (using `cmd+shift+p`) -->

### Possible fixes

Use `vscode.MarkdownString` rather than `string` for the MR body.

Story points: 1.0
Advanced search is broken + minor errors in issuable search

### Summary

The extension has a rudimentary search feature (it shows you input box and then it opens the web search results for you).

There are 3 commands: 

-  `GitLab: Search Project Issues (Supports Filters)`
- `GitLab: Search Project Merge Requests (Supports Filters)`
- `GitLab: Project Advanced Search (Issues, MR's, Commits, Comments...)`

The advanced project search doesn't work. The remaining searches are sometimes throwing errors (no user-facing defects though).

### Steps to reproduce

1. Open GitLab project in VS Code
2. run the `GitLab: Project Advanced Search (Issues, MR's, Commits, Comments...)`
3. type in any query that would normally return results
4. see that the search results are empty

### What is the current _bug_ behavior?

The extension creates URL with `project_id=undefined` in it and the search results are empty.

### What is the expected _correct_ behavior?

The extension creates correct URL and there are search results.

### Relevant logs and/or screenshots

![dependency___Search___GitLab](/uploads/f481536c1f1d678b351622e2f2199ebd/dependency___Search___GitLab.png)

### Possible fixes

We use `project.id` in `search_input.js`, we should use `project.restId`. Best solution is to migrate this small file to TS, which would discover such an issue.

Story points: 1.0
Implement OAuth token refreshing



### Problem to solve

When we generate an access token using the OAuth flow (https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/560), the token will expire (by default in 2 hours). 

### Proposal

Ask for a new token using the `refresh_token` https://docs.gitlab.com/ee/api/oauth2.html#authorization-code-with-proof-key-for-code-exchange-pkce.

### Further details

We'll need to keep track of when the original token has been generated and refresh it when the extension want's to use it after its expiration time.

### Links / references

Story points: 2.0
Implement OAuth flow for `gitlab.com`

### Problem to solve

Users have to [log in with generated personal access token](https://gitlab.com/gitlab-org/gitlab-vscode-extension#setup).

### Proposal

Allow OAuth authorization so user's can log in to `gitlab.com` without generating token.

### Further details

https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/221#note_885722819

### Links / references

Story points: 2.0
Fix /merge quick action by submitting head SHA with the new note


### Summary

The `/merge` quick action in any MR comment causes the API to fail. Original issue: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/352

![merge-quick-action](/uploads/27f47835194fa6553869733be9523f91/merge-quick-action.mp4)

### Steps to reproduce

Try to send a comment on an open MR that contains the `/merge` quick action.

### What is the current _bug_ behavior?

GitLab API fails with 500 error.

### What is the expected _correct_ behavior?

The MR gets merged.

### Relevant logs and/or screenshots

<!-- Logs can be found by running `GitLab: Show extension logs` command (using `cmd+shift+p`) -->

### Possible fixes

We need to submit the `CreateNoteInput.mergeRequestDiffHeadSha` parameter to the GraphQL `createNote` mutation. This parameter should contain the MR HEAD SHA and it is used for optimistic locking.

Maybe we'll need to add a condition and only submit the parameter if the GitLab version is 14.9 or higher. I'm not 100% sure how GraphQL handles input parameters that are not defined (because the `mergeRequestDiffHeadSha` parameter won't be defined on older versions)

Story points: 1.0
POC - OAuth GitLab login in addition to token login

### Problem to solve

The current way of generating Personal Access token and adding it to the extension is relatively complicated and prone to errors. More information is in the original issue https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/221

### Proposal

In the proof of concept we would test the OAuth login locally:

1. Create an [instance-wide OAuth application](https://docs.gitlab.com/ee/integration/oauth_provider.html#instance-wide-applications) in the local GDK
1. Create a page that GitLab redirects to when user gives the OAuth permission
    - Try localhost server triggered by the extension (this is how JetBrains GitHub plugin does it)
    - If that doesn't work, we can try to use GitLab Pages (that's similar to how the VS Code GitHub extension does it)
1. Implement the OAuth flow in the extension

### Further details

This is going to be proof-of-concept with throwaway code. The output is going to be:

- POC code in the extension
- Documentation on how to set up the OAuth application in the GitLab instance.
- It would be good to think how could this OAuth flow be adjusted for alternative VS Code deployments (Gitpod or `vscode.dev`) but that might be out of scope for this quick spike.

### Links / references

Story points: 2.0
Reintroduce minimal GitLab version warning

<!---
Please read this!

Before opening a new issue, make sure to search for keywords in the issues
filtered by the "feature" label:

- https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues?label_name%5B%5D=feature

and verify the issue you're about to submit isn't a duplicate.
--->

### Problem to solve

There are currently two version-related checks that could cut down on our triage/support time:

* [The README note](https://gitlab.com/gitlab-org/gitlab-vscode-extension#minimum-supported-version) - I have doubts that many people would install the extension, read this part of readme and double-check their GitLab instance version.
* [The Bug.md issue template](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/.gitlab/issue_templates/Bug.md) - From my experience maybe 20% of bug reports use that template, the rest is people clicking "New Issue" and describing their problem in the description.
  * I sometimes follow up and ask the issue creator to double-check their version but not always

The checks that we have in place are (IMO) not successful at letting people know they are using an unsupported GitLab version (unless they use the two features specified in [feat: remove minimal version requirement in favour of per-feature checking](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/342)).

### Proposal

Reintroduce the minimal version check that we removed in https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/342

Set the minimum supported version to 13.0

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->

### Links / references

Story points: 1.0