You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Symptom: Every checkmarx command (project list/get, scan list/get/stats) and config test/config check's checkmarx probe now fail with HTTP 404 Not Found. Requests are sent to https://<tenant>.cxone.cloud/api/api/projects (doubled /api) instead of https://<tenant>.cxone.cloud/api/projects.
Repro:pncli checkmarx project list with checkmarx.baseUrl = https://vcr.cxone.cloud/api → {"ok":false,"error":{"status":404,"message":"HTTP 404 Not Found","url":"https://vcr.cxone.cloud/api/api/projects?limit=100"}}. Every other checkmarx subcommand (project get, scan list/get, scan stats) shows the identical /api/api/... doubling.
Expected: Request should go to https://vcr.cxone.cloud/api/projects (no doubled segment).
Notes: This is a direct regression from the BUG-23 fix (PR fix: preserve base URL path segments in buildUrl() for Managed Dynatrace hosts #284, 87fef4b). CheckmarxClient (src/services/checkmarx/client.ts) builds every endpoint path with a leading /api/... (e.g. /api/projects, /api/scans, /api/results/summary), and pncli's documented/example config convention for checkmarx.baseUrlalready includes a trailing /api (e.g. https://<tenant>.cxone.cloud/api — see skills/pncli/checkmarx.md and this repo's .env.example). Under the old, buggybuildUrl(), an absolute-path reference resolved against the origin only, so the base's own /api was silently discarded and the request happened to land on the right URL "by accident" (origin + /api/projects == the intended URL). Now that buildUrl() correctly preserves the base's path, the base's own /api and the client's own leading /api both survive and get concatenated, producing /api/api/projects. This means the previous "working" checkmarx behavior relied on the exact same URL-resolution bug this session already flagged as BUG-23/BUG-4 — fixing it for Dynatrace unmasked a latent path-convention mismatch in the Checkmarx client. Fix options: (a) change CheckmarxClient's paths to be relative (drop the leading /api/, i.e. just projects, scans, results/summary) since baseUrl already supplies it — mirrors how BUG-4 was fixed for Artifactory; or (b) change the documented checkmarx.baseUrl convention to be the tenant root (no trailing /api) and keep the client's /api/... paths as-is. Option (a) requires no user-facing config changes and is recommended.
87fef4b) — regression introduced while fixing BUG-23checkmarxcommand (project list/get,scan list/get/stats) andconfig test/config check's checkmarx probe now fail withHTTP 404 Not Found. Requests are sent tohttps://<tenant>.cxone.cloud/api/api/projects(doubled/api) instead ofhttps://<tenant>.cxone.cloud/api/projects.pncli checkmarx project listwithcheckmarx.baseUrl = https://vcr.cxone.cloud/api→{"ok":false,"error":{"status":404,"message":"HTTP 404 Not Found","url":"https://vcr.cxone.cloud/api/api/projects?limit=100"}}. Every other checkmarx subcommand (project get,scan list/get,scan stats) shows the identical/api/api/...doubling.https://vcr.cxone.cloud/api/projects(no doubled segment).87fef4b).CheckmarxClient(src/services/checkmarx/client.ts) builds every endpoint path with a leading/api/...(e.g./api/projects,/api/scans,/api/results/summary), and pncli's documented/example config convention forcheckmarx.baseUrlalready includes a trailing/api(e.g.https://<tenant>.cxone.cloud/api— seeskills/pncli/checkmarx.mdand this repo's.env.example). Under the old, buggybuildUrl(), an absolute-path reference resolved against the origin only, so the base's own/apiwas silently discarded and the request happened to land on the right URL "by accident" (origin + /api/projects== the intended URL). Now thatbuildUrl()correctly preserves the base's path, the base's own/apiand the client's own leading/apiboth survive and get concatenated, producing/api/api/projects. This means the previous "working" checkmarx behavior relied on the exact same URL-resolution bug this session already flagged as BUG-23/BUG-4 — fixing it for Dynatrace unmasked a latent path-convention mismatch in the Checkmarx client. Fix options: (a) changeCheckmarxClient's paths to be relative (drop the leading/api/, i.e. justprojects,scans,results/summary) sincebaseUrlalready supplies it — mirrors how BUG-4 was fixed for Artifactory; or (b) change the documentedcheckmarx.baseUrlconvention to be the tenant root (no trailing/api) and keep the client's/api/...paths as-is. Option (a) requires no user-facing config changes and is recommended.Service: Checkmarx
Submitted via kolatts.github.io/pncli