giseldo/neodataset huggingface dataset:
No pipeline nor MR found for current branch

### Summary

I have been using the extension smoothly for many month but a few days ago it stopped properly linking the remote branch MRs and Pipelines. When I am on master/main it still works, but as soon as I switch to any other branch it stops showing the latest MR and pipeline status in the bottom bar. In the extension sidebar is stills shows the project merge requests though... I have uninstall and re-install, but this did not fix the issue.

![image](/uploads/735c95a3d496e5a4e0d0d181ddb74feb/image.png)  

### Steps to reproduce

See above

### Relevant logs and/or screenshots

Nothing particularly suspicious in the logs:
```
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
[info]: Found https://gitlab.com in the PAT list and git remotes, using it as the instanceUrl
```

Story points: 1.0
Validate personal access token right after the user added it

### Problem to solve

Users can add a personal access token that is invalid or expired, or they make a typo when entering the instance URL.

The extension will save this potentially incorrect pair (instance URL, token) and the user will find about the invalid token later when they try to use some of the extension functionality

### Proposal

Validate the token instantly after the user adds it. We can do that by calling `instanceUrl/api/v4/version` API endpoint.

### Further details

Thanks @pslaughter for suggesting this ~"type::feature" 

### Links / references

Story points: 1.0
Remote repositories not showing all files



### 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.38.1
- [x] I'm using the latest VS Code version ([find the latest version here](https://github.com/microsoft/vscode/releases))
  - VS Code version: Latest insiders
- [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

The extension loads a maximum of 20 files in the folder, if the folder has got more files/folders than that, the remote repository won't show them.

| local repository | remote repository |
| ------ | ------ |
| ![image](/uploads/733d37a1fb933a419b18c9fec9444e50/image.png) | ![image](/uploads/746bbc525e2606ce3133d908404d65b1/image.png) |


### Steps to reproduce

Open https://gitlab.com/gitlab-org/gitlab-vscode-extension as a remote repository, then open the `src/` folder.

### What is the current *bug* behavior?

The `src` folder has only 20 files.

### What is the expected *correct* behavior?

The `src` folder shows all the files


### Possible fixes

We need to make sure we load all pages if the REST API result is paginated

Story points: 1.0
Feature Request: Pipeline view does not show stages containing manually triggered jobs

<!---
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.
--->  There is no issue with a "feature" label as of submission time

### Problem to solve

As a developer using this feature to monitor pipelines for the projects I work on, some of the pipelines contain stages containing [manual jobs](https://docs.gitlab.com/ee/ci/jobs/job_control.html#create-a-job-that-must-be-run-manually).  In the pipeline view for the extension, I do not see these stages nor can I manually trigger any of these jobs despite the stage containing these manual jobs also containing non-manual jobs.  Being able to view and trigger these jobs would allow for me to do more pipeline management from within VS code without having to use the web API.

### Proposal

Extend the pipeline view to include viewing manual jobs and the ability to trigger them.

### Further details


### Links / references

Story points: 2.0
Extension ignores expired token and fails in the wrong place

Original title: (*Open Active File on GitLab fails with Cannot read property 'webUrl' of null*)

### Checklist

- [x] I'm using the latest version of the extension 3.34.0 ([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*
- [x] I'm using the latest VS Code version ([find the latest version here](https://github.com/microsoft/vscode/releases))
  - VS Code version:
Version: 1.61.2
Commit: 6cba118ac49a1b88332f312a8f67186f7f3c1643
Date: 2021-10-19T15:49:28.381Z
Electron: 13.5.1
Chrome: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin x64 20.6.0
- [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.4.0-ee
### Summary

When I use the "Open Active File on GitLab" fails with Cannot read property 'webUrl' of null

### Steps to reproduce

Use an expired token to set up the extension.

Open any file and execute the "Open Active File on GitLab" command.

### What is the current *bug* behavior?

Nothing happens. No error, no browser window opened.

Before I updated it used to give this error:

```
Cannot read property 'webUrl' of null
TypeError: Cannot read property 'webUrl' of null
at getActiveFile (/Users/myusername/.vscode/extensions/gitlab.gitlab-workflow-3.33.0/out/src/openers.js:91:39)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async openActiveFile (/Users/myusername/.vscode/extensions/gitlab.gitlab-workflow-3.33.0/out/src/openers.js:103:33)
at async /Users/myusername/.vscode/extensions/gitlab.gitlab-workflow-3.33.0/out/src/extension.js:36:9
at async _executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:94:110871)
```

### What is the expected *correct* behavior?

It should open a browser window with the file I selected.

### Relevant logs and/or screenshots

It looks like my logs are empty.

Story points: 1.0
Validate that instance URL starts with protocol

### Problem to solve

Currently, users can add GitLab instance URLs that do not start with the protocol. This can happen in both the `gitlab.instanceUrl` setting and the instance URL specified when adding token.

This sometimes makes extension setup more confusing (e.g. #481).


### Proposal

When the user adds a token, validate that the instance URL starts with a protocol (either `http://` or `https://`).

When the extension notices a `gitlab.instanceUrl` setting, it warns user if the setting doesn't start with a protocol.

### Further details

This would work well with https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/515


### Links / references

Story points: 1.0
request: support vscode browser based extension (vscode.dev)

<!---
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

<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->

As a developer I want to open my web browser to https://vscode.dev/gitlab.mycorp.com/mygroup/myproject/-/merge_requests/3 and to be able to see the code/MR, so I can use vscode just by clicking a link

### Proposal

<!-- How are we going to solve the problem? -->

potentially make the extension support web extensions, at least partially 

https://code.visualstudio.com/api/extension-guides/web-extensions#update-existing-extensions-to-web-extensions

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->

If I have a lot of projects and merge requests get created, I'd rather be able to click a link to open an editor than open the editor, clone the repo, etc

[remote-fs-url-format.md](docs/user/remote-fs-url-format.md) is cool, but can't seem to open up a merge request or use the plugin from that view

`code --folder-uri 'gitlab-remote://gitlab.mycorp.com/myproject?project=35595&ref=master'`

### Links / references

Story points: 2.0
Pipeline status term mismatch: Succeeded

## :speech_balloon: Term mismatch

The VSCode extension uses the term **Succeeded** for pipelines and jobs that finished without errors or warnings (green check mark) in the sidebar. The extension also uses **Passed** for pipelines in the bottom status bar. Meanwhile, the GitLab platform just uses the term **Passed** (except for [MWPS](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html#merge-when-pipeline-succeeds)).

| Current (extension) | [Reference](https://gitlab.com/KevSlashNull/empty-brackets-in-extension/-/pipelines/391382511) (in GitLab) | Expected (extension) |
| --- | --- | --- |
| ![image](/uploads/2f8faaee6f2cdda63eab1c63c278752a/image.png) | ![image](/uploads/2393c667199e5a3c4a8248232e585396/image.png) | ![image](/uploads/76257b292c3cbfec6bb641cabceb11f5/image.png) |

| Status bar term |
| --- |
| ![image](/uploads/77ddf0e8b3f738dcd2938e147a6dfe3c/image.png) |

## :bulb: Proposal

Use the term **Passed** in the extension to be consistent with the UI text in the GitLab platform.

Story points: 1.0
flaky test: Pipeline actions - creates  new pipeline

The test failed on master https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/jobs/1657306279, rerun fixed the pipeline.

Failed assertion: https://gitlab.com/gitlab-org/gitlab-vscode-extension/blob/400425fb1819824b3455f8fce3c1ccb96f6bbe68/test/integration/pipeline_actions.test.js#L51

I assume that the new refreshing logic introduced in #60 refreshes more than once and the `calledOnce` assumption fails.

Story points: 1.0
Helping users set the correct remote name

### Problem to solve

Currently, when user has got multiple remotes in the same repository (e.g. `origin` and `upstream`) the GitLab Workflow extension silently selects the (alphabetically) first one (`origin` in this example).

Users can select remote to be used by setting the `gitlab.remoteName` (https://gitlab.com/gitlab-org/gitlab-vscode-extension#extension-settings). But that is not obvious to the user.

### Proposal

When we detect multiple remotes in the repository, we'll ask user which one they want to use and store it into the workspace settings (`gitlab.remoteName`)

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->

### Links / references

- more context https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/433#note_662047082

Story points: 2.0
Can't access Issue detail from self-hosted gitlab (`Cannot read property 'full' of undefined`)

### Checklist

- [X] I'm using the latest version of the extension
  - Extension version: *v3.29.1*
- [X] I'm using the latest VS Code version
  - VS Code version: *1.51.1*
- [X] I'm using a supported version of GitLab
  - GitLab version: *14.2.1*

### Summary

I can see the list of issues associated with the current branch ![image](/uploads/2b208ecc8d687dbd0b2c778b1b236689/image.png)

But when I click on one of those issue they just display "Fetching issuable details and discussions. This may take a while."

This bug is similar to (#297) but the error message is different.

### Steps to reproduce
 - open VS Code
 - go to the GitLab Workflow tab
 - click on on of the issues associated with the current branch

### What is the current *bug* behavior?

It opens a tab with only "Fetching issuable details and discussions. This may take a while."

### What is the expected *correct* behavior?

To see the same thing that if I access the issue through "Issues created by me"

### Relevant logs and/or screenshots

The logs gives:
```
Cannot read property 'full' of undefined
TypeError: Cannot read property 'full' of undefined
	at getProjectPath (/home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/gitlab/gitlab_new_service.js:67:58)
	at GitLabNewService.getDiscussions (/home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/gitlab/gitlab_new_service.js:235:29)
	at GitLabNewService.getDiscussionsAndLabelEvents (/home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/gitlab/gitlab_new_service.js:290:18)
	at initPanelIfActive (/home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/webview_controller.js:32:57)
	at processTicksAndRejections (internal/process/task_queues.js:93:5)
	at async WebviewController.create (/home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/webview_controller.js:143:9)
	at async WebviewController.open (/home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/webview_controller.js:130:26)
	at async /home/pouxa/.vscode/extensions/gitlab.gitlab-workflow-3.29.1/out/src/extension.js:35:9
	at async _executeContributedCommand (/opt/visual-studio-code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:85:109243)
	at async _executeContributedCommand (/opt/visual-studio-code/resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:85:109243)
```

Story points: 1.0
Optimize packaged extension

[esbuild](https://github.com/evanw/esbuild) is an extremely fast JavaScript/TypeScript bundler. On my (admittedly powerful) PC, esbuild can bundle (and minify) this extension in ~40ms.

The main advantage is a reduction in the number and size of files loaded by VSCode. Currently, the packaged extension contains ~3500 files:

* `node_modules/` - ~2900 files
* `out/` - ~400 files
* `src/` - ~200 files - **these should be added to .vscodeignore**, since source files are not needed at runtime
* Miscellaneous other - 25 files

Using esbuild can reduce the total file count to ~30 by bundling each entry point into a single file, thus eliminating `node_modules` and `out`. AFAIK, there are two entry points: main and webview.

Removing `src` reduces the extension size by 2.2MB. Bundling the main entry point and eliminating `node_modules` and `out` reduces the extension size by 9MB. This is size of the files, after unpacking the extension from the .vsix/ZIP. This does not include the webview, because I'm not sure how to use esbuild with Vue.

I am interested in submitting an MR.

Story points: 2.0
Spike: Debug custom SSL Certificate issues

### Summary

The extension has issues connecting to instances that use a self-signed SSL certificate (not signed by a root authority included in `node`) (Epic: https://gitlab.com/groups/gitlab-org/-/epics/6244). The goal of this spike is to create a local environment where the server uses self-signed certificate. In this environment, we are going to test setting up the `gitlab.ca`, `gitlab.cert`, `gitlab.certKey`, and `gitlab.ingnoreCertificateErrors`.

### Output of this spike:

1. Documentation about the current support of self-signed certificates in the README - this will help users to set up their extension. If the extension doesn't support self-signed certificates, we'll document that.
1. Triage of existing issues in https://gitlab.com/groups/gitlab-org/-/epics/6244
1. If `cross-fetch` (our library for making HTTPS requests) doesn't support self-signed SSL, this spike will document possible alternatives

Story points: 2.0
Move documentation images away from the `main` branch

### Problem to solve

We currently store all documentation images in [`src/assets` on the `main` branch](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/tree/main/src/assets).

The images currently take about 13 MB.

This has several problems:

- It increases the size of the repository for cloning
- All pictures need to be referenced in `README.md` with absolute URLs (because [the README is also rendered in the Marketplace](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow))
  - this means that we need to use links in a format like https://gitlab.com/gitlab-org/gitlab-vscode-extension/raw/main/src/assets/_diff-comments.gif in the MR, but they don't work till the MR gets merged to `main`
- The images are in the wrong folder (I'd expect `src/` folder to contain files needed for the extension runtime)
- some of these images get packaged with the extension, where they increase the download size without any purpose (this could be "fixed"[^1] without removing the images from `main`)

   <details>

    ```
    ~/.v/e/g/s/assets ❯❯❯ ll
    Permissions Size User  Date Modified Name
    .rw-r--r--   27k tomas 13 Jul 15:01  gitlab-logo.png
    .rw-r--r--  207k tomas 13 Jul 15:01  gitlab-vscode.png
    drwxr-xr-x     - tomas 13 Jul 15:01  images
    .rw-r--r--  892k tomas 13 Jul 15:01  insert-multi-file-snippet.gif
    .rw-r--r--  149k tomas 13 Jul 15:01  logo.png
    .rw-r--r--   44k tomas 13 Jul 15:01  pipeline-actions.png
    .rw-r--r--   74k tomas 13 Jul 15:01  screencast-cover.jpg
    ~/.v/e/g/s/assets ❯❯❯ pwd
    /Users/tomas/.vscode-insiders/extensions/gitlab.gitlab-workflow-3.26.0/src/assets
    ```

    This is controled by the expression in [`.vsignore` file](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/.vscodeignore)

    </details>

### Proposal

There are two options I can think of:

- put the images outside of git (e.g. imgur.com)
- put the images into a separate git branch (e.g. `images` or `documentation-assets`) and make this branch protected

My preference would be the `images` protected branch.

### Further details

The migration must happen in several steps:

1. copy the images outside of the `main` branch and change the links in `README.md`
1. **Wait for a few months** (because older versions of the README still reference the resources in `main` branch)
1. Remove the images from the main brach.

### Links / references

[^1]: Fixed is in quotes because, without some automated checking, we are bound to forget to put the `_` prefix to some future documentation image.

Story points: 1.0
Change behaviour of the extension based on GitLab version

### Problem to solve

Currently we support all GitLab versions from 13.5 onwards [1](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/359). But sometimes we either need to introduce a new feature that's only supported in newer versions of GitLab or we need to fix a bug (https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/397) in different ways for the latest GitLab version and the older versions.

### Proposal

We are parsing the version for the GitLab instance since https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/252. We can reuse this logic and create a branching based on it:

```js
function getSnippetContent(){
  if (semver.lte(version, '14.1.0') {
    return getSnippetContentLegacy();
  }
  return getSnippetContentNew();
}

/* REMOVE AT 14.1.x: deprecated, doesn't work for versions lower than 14.1.0, remove when we stop supporting 14.0.x */
function getSnippetContentLegacy(){
}
```

### Further details

This might be tricky when we change GraphQL queries to match the new functionality. When GraphQL receives a query for a parameter that doesn't exist, it errors out instead of ignoring that parameter. This is going to be problem if we want to only introduce a feature for newer GitLab versions but the older instances would start returning errors for the whole query.

### Links / references

Story points: 2.0
Pipelines progress and logs views

I use most of the features in gitlab and found gitlab vscode intact with all the features except gitlab CI is the best service and awesome tool that I use everyday in every project.

### Problem to solve

As a developer who spend all working hours in vscode, I would love to see all pipelines with logs and jobs.

![test-unit___1391199576____Jobs___GitLab_org___gitlab-vscode-extension___GitLab_and_fish__Users_tomas_and_Slack_____Google_Calendar___GitLab](/uploads/be4ae16fe815adc6da8550ac67b637c2/test-unit___1391199576____Jobs___GitLab_org___gitlab-vscode-extension___GitLab_and_fish__Users_tomas_and_Slack_____Google_Calendar___GitLab.png)


### Proposal

<!-- How are we going to solve the problem? -->

### Further details

<!-- Include examples, use cases, benefits, goals, or any other details that will help us understand the problem better. -->

### Links / references

Story points: 2.0