@gitkraken/core-gitlens 0.6.0 → 0.7.1

package/CHANGELOG.md

@@ -6,6 +6,37 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 ## [Unreleased]
 
+## [0.7.1] - 2026-09-24
+
+### Added
+
+- Adds Bitbucket Data Center to the filtered pull-request search and its count probe ([#5875](https://github.com/gitkraken/vscode-gitlens/issues/5875)). `getSupportedFilters(BitbucketServer).pullRequestSearch` now declares the relationships `Author`, `ReviewRequested` and `Reviewed`, the states `open`/`closed`/`merged`/`all`, `text`, `draft`, `includeArchived`, the repository scope and the sorts `updated:desc`/`updated:asc` — and nothing its REST API cannot express: no assignee or mention (its pull requests have neither), no date filters, no `created` order, and no organization scope, since there is no project-wide pull-request list. `searchPullRequestsPage` reads each requested repository × relationship as its own request, or the user's dashboard for a relationship without repositories (`Reviewed` as its reviewer and participant lists, since the dashboard only filters by review status together with a role), follows every facet's own `nextPageStart` so matches past the first page are found, and binds its cursor to the connection, the configured installation URL (context path included) and the query, refusing it under anything else. Every criterion is re-checked on the rows returned, so a server that ignores one (`draft` before 8.18) narrows the page instead of widening it, and a repository that fails is reported as a scoped warning with `fetchFailed` while the others still answer, and is retried once at the page it missed before being dropped. `countPullRequests` applies the same facets and predicates, so its count is exactly the number of rows the search returns — the union of the requested states, unlike GitHub's per-state maximum. Bitbucket Data Center has no count query, so it reads each facet's first page of up to 1,000 and reports a larger scope as a floor through the new optional `PullRequestCountResult.lowerBound`. Its pull requests now also report `isDraft` from the server's `draft` field rather than always `false` (plus/integrations)
+- Adds Azure DevOps Server to the filtered searches and their counts ([#5876](https://github.com/gitkraken/vscode-gitlens/issues/5876)). `searchIssuesPage` and `countIssues` run one collection-scoped WIQL query, so every relationship is OR-ed in a single query and the count is the exact size of the match set the search pages through. `searchPullRequestsPage` and `countPullRequests` drain each repository or project facet, apply text, draft and dates the pull request API can't filter by, union by repository identity and page the ordered result from a keyset cursor. `getSupportedFilters()` declares only what each search implements, a search that would span collections is refused rather than widened, and past a result ceiling the read reports a `provider-limit` omission (with `limit` and `sort`, and no invented total) and the count `exceedsProviderLimit` instead of an understated number. `ProviderIssueSearchPage`/`ProviderPullRequestSearchPage` gain `limitReached` for such a ceiling, and a provider count slot may now refuse its own scope without failing the batch (an `Error` in `ProviderSearchCount` for issues and in `ProviderPullRequestCount | Error` for pull requests), or, for issues, report `'exceeds-limit'`. Every request stays on the selected connection's installation, with the collection applied once. Scope names are no longer refused for spaces or quotes on this provider, since it never puts them in a query string. `broadenIssues` now uses the collection search for Azure DevOps Server instead of draining repositories. Azure DevOps Services is unchanged (plus/integrations)
+
+### Fixed
+
+- Fixes domainless self-managed Git issue associations resolving through an arbitrary primary or cached host ([#5883](https://github.com/gitkraken/vscode-gitlens/issues/5883)). `getIssueFromGitConfigEntityIdentifier` accepts an optional `getConfiguredIntegrations` callback and resolves a legacy association only when those connections identify exactly one host. Missing configuration or multiple hosts leave it unresolved, including cache-only reads. New Bitbucket Server issue identifiers carry their domain; existing domainless identifiers retain the single-host read path, and pull request identifiers keep their persisted shape. Jira Server still requires an explicit domain (plus/integrations)
+- Fixes `IntegrationService.getMyIssues` and `getMyPullRequests` reading only one host of a self-managed provider ([#5873](https://github.com/gitkraken/vscode-gitlens/issues/5873)). Both resolved each id with `get(id)` and no domain, which answers with a single instance (the first cached, else the primary configured host), so a user connected to two GitHub Enterprise servers, GitLab instances, Bitbucket Data Centers, Azure DevOps Servers or Jira Data Center instances got results from one of them and no sign the others were skipped. Every self-managed id is now read on each configured host, local and cloud connections alike, and both reads run within `providerFanOutConcurrency`. A failing host still leaves the others' results in place, and results are not deduplicated on key, since two hosts routinely share `owner/repo#number`. With `openRepositoriesOnly`, multiple hosts receive only repositories whose remotes match exactly one host: by host and port for web remotes, or by hostname for SSH remotes. Ambiguous SSH remotes are skipped. A single host retains all of its provider's open repositories, including SSH aliases. `getRemoteHostMatcher` and `isWebRemoteScheme` move to `utils/domain.utils` for that (plus/integrations)
+- Fixes branch-associated GitHub Enterprise and GitLab self-hosted issues being read back from the wrong host. `getEntityIdentifierInput` only recorded a `domain` when it rewrote a `github`/`gitlab` provider id, so an issue read through the self-managed integration, which already carries the enterprise id, was encoded with no host. It now records the host for those issues. The resolver passed to `getIssueFromGitConfigEntityIdentifier` receives the identifier's `domain` as a second argument, which a self-managed provider must honor. A resolver that ignores it keeps compiling and keeps its old behavior. Pull request identifiers are unchanged, since they are also the Launchpad uuid that stored pins and snoozes key on, and legacy issue identifiers without a host use the single-host compatibility path described above (plus/integrations)
+- Fixes Azure DevOps Server's relationship-filtered pull request and issue reads matching nothing or failing ([#5876](https://github.com/gitkraken/vscode-gitlens/issues/5876)). Verified against a live Azure DevOps Server 2020: a person has one identity id at the server level and another in each collection, and the creator/reviewer filters only match the collection's, so the account-wide "my pull requests" read returned an empty account. It now resolves the id from each collection's own connection data. The repo-scoped reads, and the identity lookup behind their filters, also sent a PAT as a bearer token, which Azure DevOps Server refuses with `401`; they now send it as the Basic credential every other Azure read uses. Azure DevOps Services keeps its single account id, and its PAT sessions now send the PAT the same way on those repo-scoped reads (plus/integrations)
+- Fixes an Azure DevOps Server connection addressed at a collection (`https://server/tfs/DefaultCollection`) failing every account-wide read ([#5876](https://github.com/gitkraken/vscode-gitlens/issues/5876)). Azure DevOps Server only lists collections at the server level and answers the route below a collection with a 404 page, so discovery failed; it now reports the collection that address names, read from the collection's own connection data. Organization and project links, repository lists by organization, account-wide issue reads, single issue reads, merges and the legacy pull request search also applied the collection a second time on such an address, and now apply it once (plus/integrations)
+
+## [0.7.0] - 2026-09-22
+
+### Fixed
+
+- Fixes self-managed integrations dropping the installation path from API requests, including Azure DevOps Server virtual directories, while keeping existing connections usable ([#5871](https://github.com/gitkraken/vscode-gitlens/issues/5871))
+- Rejects a provider response that carries an HTML page under a success status instead of handing it on as data. Azure DevOps answers a rejected credential by redirecting to its sign-in page, which then returns `203 text/html` rather than `401`, and `response.ok` spans the whole 200-299 range — so the page was read as the body and passed to provider code typed as the JSON it is not. It surfaced as an opaque `TypeError` deep inside a provider, or as nothing at all on a route returning `void`, which made a bad credential look like a successful write. Such a response now raises `UnexpectedHtmlResponseError`. On Azure DevOps, the one provider known to answer a rejected credential this way, it is classified as an authentication failure so a fan-out reports what it actually was; on every other provider it stays a request failure, because a 2xx page there is far more likely a maintenance or WAF interstitial and calling that an auth failure would expire a valid cloud session and count against the budget that disconnects the integration. A page mislabelled as JSON is caught the same way, since `<` can never open valid JSON, and content types are matched case-insensitively as the spec requires. An empty body is exempt, since a write answering `204` can carry a stale `text/html` from its endpoint's usual responses and a sign-in page is never empty. The response attached to the error is stripped of its credential-bearing headers (the session cookie Azure sets, the challenges whose payload names the tenant) and its body cut to a diagnostic prefix, because an error is something a consumer may reasonably log or forward. Azure DevOps' own REST client takes the same guard on its direct reads, where the page previously reached `rsp.json()` and died as a bare `SyntaxError` that every caller reported as a missing work item. An `AuthenticationError` now propagates out of every one of those reads — the work-item and linked issue-or-PR lookups, the PR-for-branch and PR-for-commit reads, the current-user read, the repository-metadata and default-branch probes, which degrade quietly on a 404 by design but must not on a rejected credential, and the work-item state-list read, whose empty-list fallback was cached and so pinned every work item of that type to an unknown state long after the session recovery should have run. Everything else keeps its existing degrade-to-undefined behavior. A non-2xx keeps its own status error, which says more
+- Stops pre-encoding the Azure DevOps credential now that `@gitkraken/provider-apis` 0.59.0 encodes it. That release made `isPAT` produce a real HTTP Basic header, `base64(':' + token)`, where it previously emitted the token verbatim after `Basic ` — so every caller had to encode the pair itself, as this package did via `convertTokentoPAT`. Left alone, the secret would have been encoded twice and refused by Azure DevOps on every SDK-backed read; the raw secret is now handed over and provider-apis encodes it. The one observable change is the Basic username, which goes from `PAT` to empty — the form Azure DevOps documents and the SDK verified live. Azure DevOps' own REST paths in this package build their header directly and are unaffected, as is `getCurrentUser`, which asks for a bearer token
+- Fixes account-wide GitHub issue reads ignoring `itemsPerPage`. The facade dropped the requested size before `searchMyIssues`, so its three aliased searches defaulted to 100 full issue nodes and could exceed GitHub's GraphQL complexity limit. The page size now reaches every alias; omitted values keep the existing 100-item default. (plus/integrations, plus/git-github)
+
+### Added
+
+- Adds paginated discovery of Bitbucket Data Center projects and repositories, including project-scoped reads, with connection isolation and warnings for incomplete results ([#5874](https://github.com/gitkraken/vscode-gitlens/issues/5874))
+- Adds Jira Server/Data Center as a self-hosted issue integration, `jira-server` ([#5864](https://github.com/gitkraken/vscode-gitlens/issues/5864)). It is the first id that is both an issue tracker and bound to a customer-run host, so the two properties are no longer fused: `IssuesSelfManagedHostIntegrationId` names the new family and the host-keyed machinery (integration and secret keys, the `connected:${id}:${domain}` flag, domain normalization, per-host primary selection, multi-account reconcile) moves to `isSelfManagedHostIntegrationId`, which spans both families, while `isGitSelfManagedHostIntegrationId` stays exactly where a read goes on to ask for repositories, pull requests or a git remote. `IntegrationKey`/`IntegrationConnectedKey` widen to match. A self-hosted instance is modelled as its own single synthetic resource, which keeps the resource → project contract of `IssuesIntegration` intact so `listOrgs`, `listProjects` and `listIssueTrackerIssuesPage` work unchanged; `listIssueTrackerIssuesPage` gains the `domain` its siblings already took. Every read is addressed to the connection's own base URL, and `ProviderAuthenticationSession` gains an optional `baseUrl` carrying the address exactly as configured: `domain` is the identity a self-managed connection is keyed by and is normalized to a bare host, so an instance mounted below a context path (`https://jira.example.com/jira`) was previously addressed at the root. The new field is populated from the wire domain on both cloud-session paths, mirrored onto `ConfiguredIntegrationDescriptor` so reconciliation can tell a re-pointed connection from an unchanged one without reading its secret (a routine check-in now re-fetches a connection whose address moved, which a normalized domain alone cannot see, refreshes the warm integration so it re-resolves rather than staying on the old path, and keys the Jira Server project cache by the address it read from rather than by host and token, which a same-token move cannot distinguish). A backend response that reports no domain keeps the address already configured rather than writing none, so a refresh cannot silently drop a context path the user never changed, and refused when it names a different host than the connection's key; `baseUrlFromDomain` (the path-preserving sibling of `hostFromDomain`) builds the URL and is now shared rather than private to `gitHostIntegration.ts`. The account-wide "my issues" read reports `truncated` when it stops at its page backstop or on a continuation the server never advances, instead of publishing the prefix as a complete account. The host guard on a self-managed cloud session now refuses only a session that NAMES a different host, and only when the fetch was scoped by a connection id WE have stored for that host (a caller-supplied or stale id is not evidence, and neither is the absence of one): the backend may return no domain at all (`toSession` defaults it to `''`), and treating that as a mismatch stranded the refresh and left the connection looking permanently disconnected — but an UNSCOPED fetch reaches the provider-global primary endpoint, whose token can belong to any configured host, so a domainless response is still refused there rather than being bound to whatever domain the caller asked for. `Integration.icon` now reports `providersMetadata.iconKey` rather than the integration id, which is what that field documents itself as and what every consumer rendering a `gl-provider-<key>` glicon needs: Jira Data Center draws with Jira's glyph, and the self-managed GitHub and GitLab ids now report the keys their metadata declares instead of ids the icon registry has no entry for. The Commit Graph's issue-integration check enumerates every configured host for a self-managed tracker rather than asking a single resolved instance, so one disconnected host no longer disables issue enrichment while another stays connected. Project issue reads address the project by its numeric id rather than its display name, since JQL resolves a `project = "<value>"` clause against key before name and a name colliding with another project's key would read that project's issues. A key that names no issue is reported as a lookup miss rather than a request failure, matching Jira Cloud's `getJiraIssueByKey` and the generic `getIssue`. Branch-association identifiers encode the host and project, since two self-hosted instances routinely issue the same issue keys, and decode back through the host they name (#5872, below)
+- Threads the host through the two point reads that serve a Jira Data Center issue, so a branch association for one now round-trips and `getTrackerIssue` serves the tracker ([#5872](https://github.com/gitkraken/vscode-gitlens/issues/5872)). `getIssueFromGitConfigEntityIdentifier`'s resolver now takes `(id, domain?)`, fed from the identifier: a Jira Data Center identifier resolves the integration for the host it names, and one that names no host is dropped rather than answered from the primary connection, which would return a different instance's issue under the same key. Identifiers encoded for the other self-managed hosts (GitHub Enterprise, GitLab Self-Managed, Azure DevOps Server) likewise resolve the integration for the host they carry rather than the primary configured one. `getTrackerIssue` gains the `domain` its paged siblings already took; `resourceId` for Jira Data Center is the host, its single resource, and no `resourceUrl` is needed because the browser link is built from the connection's own base URL. Unlike the paged reads it never falls back to the primary connection for a self-managed tracker: it requires a `domain` or a `connectionId` with a configured host and refuses otherwise, because its `issue: undefined` is a proven absence a caller may cache and two self-hosted instances routinely issue the same keys. `JiraServerIntegration` implements the resource-id point read behind it, addressed to the session's base URL like every other read, so `supportsIssueLookupByResourceId` now reports true for it
+- Adds `IssueShape.iterations` and `Issue.iterations` so consumers can access Jira sprints and Azure work-item iterations, preserving provider-reported activity and dates without inventing metadata for Azure. Coverage varies per read, and an absent value means the read couldn't report one rather than that the issue has no sprint — see "Sprints and iterations" in `docs/integrations.md`. Azure's iteration reaches both the direct work-item read, parsed here from `System.IterationPath`, and the SDK-backed reads, which requires `@gitkraken/provider-apis` 0.59.0 for the `iteration` field it normalizes; the direct read mirrors that normalization exactly — the path is the identity and is kept verbatim, so one work item cannot end up with two identities depending on which read surfaced it ([#5856](https://github.com/gitkraken/vscode-gitlens/issues/5856)).
+
 ## [0.6.0] - 2026-09-14
 
 ### Added
@@ -341,7 +372,9 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 - Initial release. Bundles `@gitlens/utils`, `@gitlens/git`, `@gitlens/git-cli`, `@gitlens/ai`, and `@gitlens/git-github` into a single core npm package with subpath exports.
 
-[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.6.0...HEAD
+[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.1...HEAD
+[0.7.1]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.7.0...gitkraken:releases/core/v0.7.1
+[0.7.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.6.0...gitkraken:releases/core/v0.7.0
 [0.6.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.116...gitkraken:releases/core/v0.6.0
 [0.5.116]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.115...gitkraken:releases/core/v0.5.116
 [0.5.115]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.5.114...gitkraken:releases/core/v0.5.115

package/README.md

@@ -28,7 +28,7 @@ import type { GitHubGitProviderInternal } from '@gitkraken/core-gitlens/plus/git
 import { OpenAIProvider } from '@gitkraken/core-gitlens/plus/ai/providers/openaiProvider.js';
 ```
 
-All exports are fully typed and source-mapped back to the original TypeScript sources shipped in `src/`.
+All exports are fully typed and source-mapped, with the original TypeScript sources embedded in the maps.
 
 ### Provider integrations
 
@@ -61,4 +61,11 @@ Independent from the [GitLens VS Code extension](https://github.com/gitkraken/vs
 
 ## Source
 
-Built from the `packages/` workspace of [vscode-gitlens](https://github.com/gitkraken/vscode-gitlens). See `packages/core/scripts/bundle.mjs` in that repo for the flattening logic.
+Built from the `packages/` workspace of [vscode-gitlens](https://github.com/gitkraken/vscode-gitlens), by `pnpm --filter @gitkraken/core-gitlens run build` in two steps:
+
+1. **`tsdown.config.ts`** compiles the eight packages' TypeScript sources straight into `dist/`, one emitted module per source module, each rooted at the subpath in the table above. It reads their `src/` directly — the packages' own manifests resolve to source, so nothing here waits on their `dist/` — and cross-package imports come out as relative paths, with `#env/*` staying external for the `"imports"` field to resolve.
+2. **`scripts/bundle.mjs`** assembles everything around that: it copies the LICENSEs and generates the manifest's `exports`, `imports`, and `dependencies` from the eight sub-packages' own manifests.
+
+Neither the subpath layout nor the generated manifest is hand-written, so adding or removing a bundled package is a one-line change to `scripts/packages.mjs`, which both steps read.
+
+The declaration files are emitted by the TypeScript compiler against `tsconfig.core-dts.json` at the repo root. That config sits at the root rather than beside this package because the emitter uses its directory as the compiler's `rootDir`, which has to contain every bundled source.

package/dist/_virtual/@oxc-project+runtime/helpers/esm/decorate.js

@@ -0,0 +1,9 @@
+//#region \0@oxc-project+runtime@0.148.0/helpers/esm/decorate.js
+function __decorate(decorators, target, key, desc) {
+	var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
+	if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
+	else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
+	return c > 3 && r && Object.defineProperty(target, key, r), r;
+}
+//#endregion
+export { __decorate as default };

package/dist/_virtual/@oxc-project+runtime/helpers/esm/usingCtx.js

@@ -0,0 +1,57 @@
+//#region \0@oxc-project+runtime@0.148.0/helpers/esm/usingCtx.js
+function _usingCtx() {
+	var r = "function" == typeof SuppressedError ? SuppressedError : function(r, e) {
+		var n = Error();
+		return n.name = "SuppressedError", n.error = r, n.suppressed = e, n;
+	}, e = {}, n = [];
+	function using(r, e) {
+		if (null != e) {
+			if (Object(e) !== e) throw new TypeError("using declarations can only be used with objects, functions, null, or undefined.");
+			if (r) var o = e[Symbol.asyncDispose || Symbol["for"]("Symbol.asyncDispose")];
+			if (void 0 === o && (o = e[Symbol.dispose || Symbol["for"]("Symbol.dispose")], r)) var t = o;
+			if ("function" != typeof o) throw new TypeError("Object is not disposable.");
+			t && (o = function o() {
+				try {
+					t.call(e);
+				} catch (r) {
+					return Promise.reject(r);
+				}
+			}), n.push({
+				v: e,
+				d: o,
+				a: r
+			});
+		} else r && n.push({
+			d: e,
+			a: r
+		});
+		return e;
+	}
+	return {
+		e,
+		u: using.bind(null, !1),
+		a: using.bind(null, !0),
+		d: function d() {
+			var o, t = this.e, s = 0;
+			function next() {
+				for (; o = n.pop();) try {
+					if (!o.a && 1 === s) return s = 0, n.push(o), Promise.resolve().then(next);
+					if (o.d) {
+						var r = o.d.call(o.v);
+						if (o.a) return s |= 2, Promise.resolve(r).then(next, err);
+					} else s |= 1;
+				} catch (r) {
+					return err(r);
+				}
+				if (1 === s) return t !== e ? Promise.reject(t) : Promise.resolve();
+				if (t !== e) throw t;
+			}
+			function err(n) {
+				return t = t !== e ? new r(n, t) : n, next();
+			}
+			return next();
+		}
+	};
+}
+//#endregion
+export { _usingCtx as default };