deploy-cli

Hello! I'm trying to migrate a website off of Deno Deploy Classic. It's a Godot game, and I can't exactly pull Godot into the Deno Deploy build infrastructure, so I'm using GitHub Actions . Back in the day, Deno Deploy Classic would use OIDC to authenticate to Deno Deploy. Does the new Deno Deploy support that, or do I have to save a token nowadays?

Fixes #123 Problem On Windows, setting in / makes collect zero files, producing an empty upload manifest. Removing restores normal collection. See #123 for full analysis and a debug trace. Root cause In , filters walked entries with . On the target (Unix path semantics), is a rooted drive path (, from → ), while -derived entries are unrooted (, from ). never matches a rooted path against a relative one, so every entry is dropped. Only reproduces on Windows with set; on Linux/macOS both forms are rooted, so behavior is unchanged (and CI cannot see the bug). Fix Add an helper that coerces → and guarantees a single leading slash, and apply it to both operands of the comparison. Rooted Unix paths are left untouched. Tests New unit test , including a sibling-prefix case to confirm the comparison stays component-wise (not raw-string). Existing still passes. Verification Authored with AI assistance; I reviewed the change to the best of my ability and verified it against my own project by pointing at the patched clone: now returns the expected files (2 config files + the built , 12 total) where it previously returned 0. passes locally.

Summary On Windows, configuring in / causes to collect zero files, so nothing is uploaded. Removing restores normal collection. This makes it impossible to whitelist a build output directory (e.g. deploying a prebuilt produced in CI) on Windows. Windows 11, Reproduction : Run . With present, . With removed, files are collected normally (but ignored directories are not collected). Root cause In , filters walked entries with: The two operands use different absolute-path representations on the target (where uses Unix semantics): comes from -> , which yields a rooted drive path: . When is set, resolves the include patterns and the walker emits entries as unrooted drive paths: . treats (absolute; leading component) and (relative) as non-overlapping, so every entry is dropped and the manifest is empty. Debug excerpt: Without , the walker traverses from the (rooted) , so entries are also rooted (), matches, and collection works. This is why the bug only appears with , and only on Windows — on Linux both forms are rooted with a leading , so it never reproduces (including in CI). Suggested fix Normalize both operands to a single rooted representation before the component-wise comparison, e.g. a helper that converts -> and ensures exactly one leading slash: and use it on both sides: This leaves already-rooted Unix paths unchanged (no behavior change on Linux/macOS) and fixes the Windows drive-letter mismatch. I have this working locally (verified via , now returns the expected files) and will open a PR with a unit test.