@postman-cse/onboarding-repo-sync 2.1.8 → 2.1.10

package/README.md

@@ -131,6 +131,7 @@ with:
 | --- | --- | --- | --- |
 | `generate-ci-workflow` | Whether to generate the CI workflow file | no | `true` |
 | `ci-workflow-path` | Path to write the generated CI workflow file. Defaults to azure-pipelines.yml for Azure DevOps, .github/workflows/ci.yml otherwise. | no |  |
+| `ci-runner-os` | Runner operating system for the generated CI workflow. Use windows for native PowerShell Azure DevOps CI. | no | `linux` |
 | `project-name` | Service project name used for environment, mock, and monitor naming. | yes |  |
 | `workspace-id` | Postman workspace ID used for workspace-link and export metadata. | no |  |
 | `baseline-collection-id` | Baseline collection ID used for exported artifacts and mock server creation. | no |  |
@@ -198,6 +199,26 @@ with:
 | `spec-version-url` | Read-only URL for the tagged Spec Hub snapshot. |
 <!-- outputs-table:end -->
 
+## Self-contained binary (no npm / no Node)
+
+For CI that cannot install npm or Node — locked-down Jenkins, bare Bitbucket agents, boxes with no package-registry access — a single self-contained executable is published as a GitHub Release asset. It bakes the Node runtime and the full bundle into one file, so the target needs no npm, no Node install, and no package-registry access. It is not network-isolated: the run still needs outbound access to the Postman API/gateway.
+
+```bash
+VERSION=2.1.10   # example: use a release that carries the binary
+ASSET="postman-repo-sync-${VERSION}-linux-x64"
+BASE_URL="https://github.com/postman-cs/postman-repo-sync-action/releases/download/v${VERSION}"
+curl -fsSLO "${BASE_URL}/${ASSET}"
+curl -fsSLO "${BASE_URL}/${ASSET}.sha256"
+shasum -a 256 -c "${ASSET}.sha256"
+chmod +x "$ASSET"
+mv "$ASSET" postman-repo-sync
+
+export POSTMAN_ACCESS_TOKEN="<minted-token>"
+./postman-repo-sync --project-name core-payments --workspace-id ws-123 --repo-write-mode commit-only --result-json postman-repo-sync-result.json
+```
+
+Credentials resolve from a CLI flag, then the `INPUT_*` env var, then a plain `POSTMAN_ACCESS_TOKEN` / `POSTMAN_API_KEY` — so Jenkins `withCredentials` works with no flag. Proxy-only agents must set `NODE_USE_ENV_PROXY=1` alongside `HTTP_PROXY` / `HTTPS_PROXY`. The binary pulls **no extra tooling onto the agent on any path** (even with a `postman-api-key`, which is only used to mint the access token). Two things to know for locked-down runs: the commit modes shell out to `git` (the binary bundles Node, not git), and with `generate-ci-workflow: true` (default) the workflow file it writes will — *when your CI later runs it* — install the Postman CLI from `dl-cli.pstmn.io`. Current target is `linux-x64`. Full runbook, credential minting, the complete host allowlist, and a Jenkins pipeline: [Self-contained binary](docs/self-contained-binary.md).
+
 ## How it works
 
 The action syncs a Postman workspace into the checked-out repository and can connect the workspace back to that repository:
@@ -268,6 +289,7 @@ Deeper reference:
 - [Artifact layout and Collection v3 format](docs/artifact-layout.md), including sync modes and versioned releases.
 - [Credentials](docs/credentials.md): `postman-api-key`, `postman-access-token`, credential preflight, GitHub tokens.
 - [CLI usage](docs/cli.md): the `postman-repo-sync` binary for GitLab CI, Bitbucket Pipelines, and Azure DevOps.
+- [Self-contained binary](docs/self-contained-binary.md): the no-npm/no-Node release binary for locked-down agents — install, credential minting, host allowlist, and a Jenkins pipeline.
 - [Security](SECURITY.md): supported releases, reporting, and secret-handling expectations.
 - [Support](SUPPORT.md): where to ask usage questions and what diagnostics to include.
 - [Release policy](RELEASE_POLICY.md): immutable version tags and the rolling `v1` alias.

package/action.yml

@@ -13,6 +13,10 @@ inputs:
   ci-workflow-path:
     description: Path to write the generated CI workflow file. Defaults to azure-pipelines.yml for Azure DevOps, .github/workflows/ci.yml otherwise.
     required: false
+  ci-runner-os:
+    description: Runner operating system for the generated CI workflow. Use windows for native PowerShell Azure DevOps CI.
+    required: false
+    default: linux
   project-name:
     description: Service project name used for environment, mock, and monitor naming.
     required: true