Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

`useJobToken` verifyConditions omits proxy, so `got` bypasses `HTTPS_PROXY`

Open Beginner friendly
  • Is something wrong?
#1,032 0 comments 0 reactions 0 assignees View on GitHub

@ar7bd is already working on this.

Since Sep 28, 2026.

  • #1033 by @ar7bd — open

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
90/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript
Domain
api

Research direction

Start in lib/verify.js at the useJobToken branch, then compare its got.get call with the PAT path and the got calls in lib/publish.js. Check lib/resolve-config.js to understand how the proxy agent is built. Done means verifyConditions uses that proxy when job-token authentication runs, including behind HTTP_PROXY or HTTPS_PROXY.

Written by the indexing model from the issue text.

Description

Description

When useJobToken: true is set, verifyConditions fails behind HTTP_PROXY/HTTPS_PROXY before any GitLab API response is received.
got does not honor those env vars by itself. This plugin builds a proxy agent in lib/resolve-config.js (hpagent) and is supposed to pass it as ...proxy on every got call.

The job-token branch in lib/verify.js does not:

if (useJobToken) {
  logger.log("Using Job Token for authentication. Some functionality may be disabled.");
  await got.get(urlJoin(projectApiUrl, "releases"), { headers: { [tokenHeader]: gitlabToken } });
} else {
  await got.get(projectApiUrl, {
    headers: { [tokenHeader]: gitlabToken },
    ...proxy,
  });
}

lib/publish.js already spreads ...proxy on got.post / got.put. Verify dies first, so those never run.

Expected

Job-token verify uses the same proxy agent as the PAT verify path and as publish.

Actual

got.get connects directly to the GitLab host. In an environment where GitLab is only reachable via the proxy (typical Docker runner with git config http.proxy $HTTP_PROXY), this fails with a connect/TLS error such as:

Error [ERR_SOCKET_CLOSED_BEFORE_CONNECTION]: Socket closed before the connection was established
  pluginName: '@semantic-release/gitlab'

Git clone/push still works because git is configured to use the proxy.

Fix

await got.get(urlJoin(projectApiUrl, "releases"), {
  headers: { [tokenHeader]: gitlabToken },
  ...proxy,
});

Patched only that line in @semantic-release/[email protected] and confirmed verifyConditions succeeds with useJobToken: true on GitLab 19.4 behind HTTPS_PROXY.

Environment

  • @semantic-release/gitlab 13.3.3
  • GitLab 19.4.1, Docker executor, HTTP_PROXY/HTTPS_PROXY required to reach the GitLab API
  • useJobToken: true, no GL_TOKEN
Dominant language
JavaScript
Stars
343
Forks
90
Avg merge
1d 54m
Merged PRs (30d)
2

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from semantic-release/gitlab

All issues in semantic-release/gitlab

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.