Tags: apify/apify-cli
Tags
feat: single apify-cli bundle + native Windows ARM64 (supersedes #1057)… … (#1169) ## What & why Reworks how the CLI bundles are built, installed, and upgraded, and adds native Windows ARM64 support. Previously the bundle install shipped **three full ~70 MB binaries** (`apify`, `actor`, `apify-cli`) — the same binary dropped three times into the install dir. This builds **one `apify-cli` bundle**; `apify` and `actor` become tiny wrapper scripts that invoke it with `APIFY_CLI_ENTRYPOINT` set, which the entrypoint uses to pick the command set. > [!NOTE] > This **supersedes #1057** (native Windows ARM bundles) — those changes are included here, adapted on top of the single-bundle work. See the "Windows ARM64" section for one deliberate deviation. ## Single-bundle layout - **Build** ([`build-cli-bundles.ts`](scripts/build-cli-bundles.ts)): build only the `apify-cli` entrypoint; additionally publish `apify-*`/`actor-*` copies as **backwards-compatible backups** so installs using the old two-bundle upgrade flow can still pull the new bundle during the transition. - **Entrypoint**: new single [`apify-cli.ts`](src/entrypoints/apify-cli.ts) entrypoint + `resolveEntrypoint()` (reads `APIFY_CLI_ENTRYPOINT`, falls back to the executable's basename). - **Install** (`install.sh` / `install.ps1`): drop the `apify-cli` binary and generate `apify`/`actor` (`.cmd` on Windows) wrapper scripts instead of three binaries. - **Self-migration** ([`bundleMigration.ts`](src/lib/bundleMigration.ts)): on the first run after upgrading from a legacy 3-bundle install, copy the running bundle to `apify-cli` and replace `apify`/`actor` with wrapper scripts. Writes are **atomic (temp + rename)** so we never truncate a running executable — an in-place overwrite fails with `ETXTBSY` on Linux (verified in a container; this matters because the `actor` CLI runs in Linux Actor images). On Windows the running `.exe` is renamed (can't be deleted) and cleaned up on a later run. - **Upgrade** ([`upgrade.ts`](src/commands/cli-management/upgrade.ts)): download the single `apify-cli` bundle, write it + the wrappers atomically. ## Windows ARM64 (supersedes #1057) Bun now ships native Windows ARM64 builds, so the old hack (compile an x64 bundle on the ARM runner and relabel it `arm64`) is gone. - Build a native `bun-windows-arm64` target; drop the `pwsh` SystemType detection + `APIFY_BUNDLE_ARCH` override. - `install.ps1`: detect arch from `PROCESSOR_ARCHITECTURE`; ARM64 never downloads a `-baseline` bundle (baseline is x64/AVX2-only). - `useCLIVersionAssets`: Windows ARM64 now matches the native (non-baseline) asset — **a fix #1057 lacks**; without it the upgrade command finds zero assets on Windows ARM64. - CI (`check`/`pre_release`/`release`): build on `windows-11-arm` with native `setup-bun` (dropped the manual install workaround) via a `bun-target-arch` matrix var. **Deviation from #1057:** asset names keep the `arm64` suffix (matching the produced artifacts, `useCLIMetadata`'s `process.arch`, and the asset matcher) rather than renaming to `aarch64`, which in #1057 mismatches the `-arm64` artifacts the build actually emits. ## Bundle target cleanup - Removed the `as never` casts on the bun compile targets. Per [Bun's supported-targets matrix](https://bun.com/docs/bundler/executables#supported-targets), `@types/bun`'s `CompileTarget` only accepts the SIMD-then-libc order, so `bun-linux-x64-musl-baseline` → `bun-linux-x64-baseline-musl` (bun accepts either order at build time). The target parser now reads the trailing modifiers order-independently and still emits the canonical `-musl-baseline` asset suffix, so **every published asset name is unchanged**. - Stopped building `bun-{darwin,linux}-arm64-baseline` (and the arm64 musl-baseline): baseline is x64-only, so these just duplicated the non-baseline arm64 builds. They're unreachable via the install/upgrade path, and download counts confirm no real usage (~205 total / max 3 per release — scraper-noise floor — vs `darwin-arm64` at 1557 / max 260). ## Testing - `pnpm run build`, `oxlint`, `oxfmt`, and the local test suite all pass. - Verified the full legacy→migrated flow end-to-end on **Linux** (arm64 container): 3 binaries → single `apify-cli` + wrapper scripts, idempotent, `actor` runs in actor mode. - Confirmed `ETXTBSY` on in-place overwrite vs success with atomic rename on Linux. - Confirmed Bun accepts `bun-windows-arm64` and the reordered `bun-linux-x64-baseline-musl` targets and appends `.exe` for Windows. Added [`dev-test-install-legacy.sh`](scripts/install/dev-test-install-legacy.sh) to reproduce the old 3-binary layout locally for testing the migration. closes #1221 --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Richard Solar <solar.richard@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
feat(create): guided wizard with use-case and language filters (#1278) Closes #1236. **TL;DR** — `apify create` becomes a guided wizard: **use case → language → best-match template**, plus `apify templates ls` for discovery. Local scaffold only; the git-sourced flow is #1237 and `--json`/`--origin` is #1238. ## What changed - **Wizard** — asks _"What do you want to build?"_ then the language, then shows one scrollable, fit-ranked template list: exact matches first (top preselected), a separator, then the closest alternatives. - **New flags** `-u/--use-case`, `-l/--language`. `-t/--template` stays authoritative and skips the wizard; `-u`/`-l` are ignored when it's passed. - **Language aliases** `js` / `ts` / `py`. No `other` option — every template has a language. - **New command** `apify templates ls [--json]`; `--json` emits the full template objects, including `useCases[]`. - **Ported** `getTemplateRecommendation` from apify-core, with two CLI changes: per-template `isExactMatch` and no result limit. ## Flag → manifest mapping | `--use-case` | manifest tag | | `--language` (+ alias) | `category` | |---|---|---|---|---| | `web-scraper` | `WEB_SCRAPING` | | `javascript` / `js` | `javascript` | | `ai-agent` | `AI` | | `typescript` / `ts` | `typescript` | | `data-pipeline` | `INTEGRATION` | | `python` / `py` | `python` | | `browser-automation` | `AUTOMATION` | | | | "Any use case" and "Any language" both mean **no filter** (`ANY_TEMPLATE_USE_CASE` / `ANY_TEMPLATE_LANGUAGE` — symmetric by design). ## Tests Unit tests for `getTemplateRecommendation` (tiers, dedup, any-language, no-exact), `buildTemplateChoiceList` (separator, labels, hint), and the flag→tag mappings; `create` covers `--template` precedence. `build` / `lint` / `format` clean, `docs/` regenerated, wizard driven end-to-end in a terminal. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Edyta <142720610+szaganek@users.noreply.github.com> Co-authored-by: David Hanuš <david.hanus@apify.com>
chore(deps): update actions/setup-python action to v7 (#1290) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/setup-python](https://redirect.github.com/actions/setup-python) | action | major | `v6` → `v7` | --- ### Release Notes <details> <summary>actions/setup-python (actions/setup-python)</summary> ### [`v7.0.0`](https://redirect.github.com/actions/setup-python/compare/v6.3.0...v7.0.0) [Compare Source](https://redirect.github.com/actions/setup-python/compare/v7.0.0...v7.0.0) ### [`v7`](https://redirect.github.com/actions/setup-python/compare/v6.3.0...v7.0.0) [Compare Source](https://redirect.github.com/actions/setup-python/compare/v6.3.0...v7.0.0) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - "every weekday" - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/apify/apify-cli). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yNzIuNCIsInVwZGF0ZWRJblZlciI6IjQzLjI4MC4wIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
feat: surface `apify help --skill` in the main help menu (#1302) ## Summary - `apify help --skill` prints the Apify CLI agent skill, but `HelpCommand` is `hidden`, so nothing pointed to it. - Adds a `LEARN MORE` line in `renderMainHelpMenu` mentioning `apify help --skill`, shown only for the `apify` entrypoint (the skill is about driving `apify` from agents, so it doesn't apply to the `actor` runtime CLI). ## Test plan - [x] `pnpm run lint` - [x] `pnpm run format` - [x] `pnpm run build` - [x] `pnpm run test:local` (pre-existing failures in 2 Python-related tests are unrelated to this change — local Python is 3.9.6, tests require 3.11+) - [x] Added unit tests asserting the line appears for `apify` and not for `actor` - [x] Manually ran `node dist/apify.js help` and `node dist/actor.js help` to confirm output Closes #1301
feat: support uv-managed Python Actors in apify create (#1274) `apify create` hard-coded `pip install -r requirements.txt` for Python Actors, so creating a uv-managed template — which ships `pyproject.toml` + `uv.lock` and no `requirements.txt` — failed during dependency install with `Could not open requirements file`. `create` now detects uv-managed Python/Scrapy projects by the presence of a committed `uv.lock` and installs their dependencies with `uv sync` instead. The check runs before the system-Python detection, since uv provides the interpreter pinned in `.python-version` itself, and falls back to a warning with install instructions when the `uv` executable isn't found. This unblocks the upcoming `python-uv` template (apify/actor-templates#800).
PreviousNext