403 Forbidden Error on Projects with Pipelines Disabled

Summary

When configuring the Gitlab Workflow Plugin with a repo that has Pipelines Disabled, the extension tosses a 403 when viewing Merge Requests. Enabling Pipelines allows Merge Requests to once again be polled and return results as expected. Gitlab in this bug report is self-hosted v13.4.2-ee and not on Gitlab.com (not sure if that matters).

Steps to reproduce

Note: this happens on gitlab.com as well.

1. Setup on-prem (non-gitlab.com) personal access token
2. Setup Settings to use the proper Gitlab Instance URL (gitlab.examplecompany.com)
3. Find/Create a repository with Merge Requests Enabled and Pipelines Disabled.
4. Attempt to use the VSCode Plugin to view MRs but receive a 403

What is the current bug behavior?

403 - Forbidden

What is the expected correct behavior?

Ability to see Active/Closed MRs, or MRs assigned to "me"

Relevant logs and/or screenshots

403 - "{\"message\":\"403 Forbidden\"}"
StatusCodeError: 403 - "{\"message\":\"403 Forbidden\"}"
	at new StatusCodeError (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/request-promise-core/lib/errors.js:32:15)
	at /Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/request-promise-core/lib/plumbing.js:97:41
	at tryCatcher (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/util.js:16:23)
	at Promise._settlePromiseFromHandler (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/promise.js:547:31)
	at Promise._settlePromise (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/promise.js:604:18)
	at Promise._settlePromiseCtx (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/promise.js:641:10)
	at _drainQueueStep (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:97:12)
	at _drainQueue (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:86:9)
	at Async._drainQueues (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:102:5)
	at Immediate.Async.drainQueues [as _onImmediate] (/Users/joel.vasallo/.vscode/extensions/gitlab.gitlab-workflow-3.6.0/node_modules/bluebird/js/release/async.js:15:14)
	at processImmediate (internal/timers.js:439:21)

Possible fixes

The fix for now is to enable Pipelines in the project settings.

The offending code in current_branch.js:

  async getChildren() {
    try {
      const workspaceFolder = await getCurrentWorkspaceFolder();
      this.project = await gitLabService.fetchCurrentProject(workspaceFolder);
      await this.fetchPipeline(workspaceFolder);
      await this.fetchMR(workspaceFolder);
      await this.fetchClosingIssue(workspaceFolder);
    } catch (e) {
      handleError(e);
      this.children.push(new ErrorItem());
    }

    return this.children;
  }

Since the fetching pipeline fails, the whole request fail. This code didn't consider that some of the calls could be still successful.