Skip to content

deploy.include from workspace root collects no workspace member files #90

@magurotuna

Description

@magurotuna

Bug Description

When deno deploy is run from a Deno workspace root, a root-level deploy.include entry that points at a workspace member is resolved to an empty include set. The file collector then uploads no files, even though the same workspace deploy config works when deploy.include is omitted.

This appears to affect both glob and file includes such as:

{
  "workspace": ["./packages/backend"],
  "deploy": {
    "org": "myorg",
    "app": "myapp",
    "include": ["./packages/backend/**"]
  }
}

and:

"include": ["./packages/backend/main.ts"]

Steps to Reproduce

Using the current main of this repository (34794b5, @deno/deploy 0.0.99):

  1. Create a workspace root with this deno.json:

    {
      "workspace": ["./packages/backend"],
      "deploy": {
        "org": "myorg",
        "app": "myapp",
        "include": ["./packages/backend/**"]
      }
    }
  2. Add a workspace member:

    packages/backend/deno.json
    packages/backend/main.ts
    packages/backend/extra.txt
    
  3. Run the deploy config resolver with debug enabled (or run deno deploy --debug from the workspace root with equivalent config).

I reproduced this directly against lib/rs_lib.js:

import { resolve_config } from "./lib/rs_lib.js";

const result = resolve_config(root, [], false, true);
console.log(result.files);

Actual Behavior

With deploy.include pointing at the workspace member, the Rust resolver logs an empty include set and collects zero files:

[rs_lib] deploy config: include=Some(PathOrPatternSet([])), exclude=PathOrPatternSet([])
[rs_lib] collect_files(root_path="/tmp/include_dir_glob-...", allow_node_modules=false, include=Some(PathOrPatternSet([])), exclude=PathOrPatternSet([])) -> 0 file(s): []

Observed for all of these variants:

"include": ["./packages/backend/**"]
"include": ["./packages/backend/main.ts"]
"include": ["./packages/backend"]

In the full CLI this produces an empty diffsync manifest / no upload, surfacing as a deployment with no files to publish (for example, No files were changed, so there is nothing to upload.).

Expected Behavior

deploy.include entries rooted at a workspace member should include the matching workspace member files when the deploy config belongs to the workspace root.

For the example above, the upload file list should contain at least:

packages/backend/main.ts
packages/backend/extra.txt

(or packages/backend/main.ts only for the explicit file include case).

Control Case

The same workspace root deploy config works when deploy.include is omitted:

{
  "workspace": ["./packages/backend"],
  "deploy": { "org": "myorg", "app": "myapp" }
}

Debug output then collects the expected workspace member files:

[rs_lib] deploy config: include=None, exclude=PathOrPatternSet([])
[rs_lib] collect_files(...) -> 4 file(s): [
  ".../deno.json",
  ".../packages/backend/deno.json",
  ".../packages/backend/main.ts",
  ".../packages/backend/extra.txt"
]

Investigation Notes

The failure seems isolated to WorkspaceDirectory::to_deploy_config(pattern) / file pattern resolution for root deploy configs that include paths inside workspace members. In the failing cases, the user-provided include patterns have already become PathOrPatternSet([]) by the time collect_files() receives them.

This is closely related to the existing regression coverage in rs_lib/src/lib.rs for workspace-root deploys including member files, but that test only covers the no-deploy.include case. A regression test should cover root deploy.include entries that target workspace member files/directories.

Environment

  • Repo: denoland/deploy-cli
  • Commit tested: 34794b5 chore: bump version to 0.0.99 (#88)
  • Deno used for repro script: deno 2.7.14 (stable, x86_64-unknown-linux-gnu)
  • Platform: Linux x86_64

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions