Overview - Adt-cli

adt-cli

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
chore/sonarcloud-fixes
e59c0cbc fix(sonarcloud-review): safe-guard JSON.stringify in S6551 helpers Address bot review feedback on PR #113 (copilot-pull-request-reviewer + kilo-code-bot, 9 threads). Core concern: JSON.stringify() can throw on circular references or BigInt values. S6551 helpers introduced in this PR call it unconditionally for any object input, which would let a malformed error object crash the CLI in the output path (info, package get/list, import-error handler) or mask the real SOAP error in adt-rfc. Wrap every user-facing JSON.stringify in a try/catch that falls back to plain String coercion. The output becomes "[object Object]" in the degenerate case, but the command finishes and the real error surfaces normally. Affected sites: - packages/adk/src/base/fetch-utils.ts (toText) - packages/adt-rfc/src/lib/client/rfc-client.ts (soap-fallback coercion) - packages/adt-cli/src/lib/utils/command-helpers.ts (handleImportError) - packages/adt-cli/src/lib/commands/package/list.ts (asStr) - packages/adt-cli/src/lib/commands/package/get.ts (toDisplay) - packages/adt-cli/src/lib/commands/info.ts (displayProperty + other-props loop) info.ts also had a behaviour-change regression flagged by kilo-code-bot: the S6551 fix changed `if (systemData[key])` (truthy) to `if (value !== undefined && value !== null && value !== '')` (explicit), which silently started displaying numeric 0 and boolean false. Restore the original `if (!value) return;` semantics since SAP system-info fields are string-shaped in practice and surfacing 0 / false would be a regression in `adt info` output. typecheck: pass on adk / adt-rfc / adt-cli.
by Petr Plenkov
Succeeded
chore/sonarcloud-fixes
4256cb18 cleanup(sonarcloud): tidy two files left with orphaned comments Follow-up on a7831b95. The S7763 codemod left two cosmetic rough edges: 1. packages/adt-cli/src/lib/ui/routes.ts The \`export { router } from './router';\` re-export was appended to the very bottom of the file, leaving the \`// Export initialized router\` comment orphaned (pointing at a closed function) at the top. Move the re-export back up under the import-trigger block where it belongs, and rewrite the comment to actually describe what's there. 2. packages/openai-codegen/src/emit/operations-interface.ts Same shape: \`export type { ResolvedNames } from './naming';\` was dangling at the bottom, with two orphaned comments about ResolvedNames up at the top of the file. Collapse the two comments into one accurate line and put the re-export next to it. No behaviour change. typecheck passes on both packages.
by Petr Plenkov
Succeeded
chore/sonarcloud-fixes
ef7b489f ci: wire NX_CLOUD_ACCESS_TOKEN via GitHub Environments Per the Nx Cloud access-tokens guide (https://nx.dev/docs/guides/nx-cloud/access-tokens#github-actions), CI jobs need `NX_CLOUD_ACCESS_TOKEN` to hit the remote cache — the earlier OIDC-only assumption was wrong. Two GitHub Environments, created via the API: - `unprotected-branch-pipeline` — read-only token, used for PR runs from feature branches. - `protected-branch-pipeline` — read-write token, gated with `deployment_branch_policy.protected_branches=true`, so GitHub only injects the secret when the job runs against `main` (or a tag on main). Workflow wiring: - `ci.yml` main job uses the protected environment on `push` events (merge to main) and the unprotected one on pull_request events. - `release.yml` release job → protected. - `publish.yml` publish job → protected (runs from the tag pushed by release). - `publish-gpr.yml` publish-gpr job → protected. Secrets themselves were set via `gh secret set --env …`, never committed. If either token ever needs to be rotated, do it in the Nx Cloud UI and re-run `gh secret set NX_CLOUD_ACCESS_TOKEN --env <env>`.
by Petr Plenkov