[falahat]

Description

Stacked on #11396. A Cloud Run source deploy of an app in a subfolder (e.g. firebase.json + functions/ + web/) zips only that subfolder, and only read .gitignore files inside it. Files ignored by a .gitignore higher up, like the project's top-level one, were uploaded, built, and could be served. App Hosting source deploys and local builds already exclude them.

The zip now also applies the .gitignore files from the project's root down to the folder it zips, like git. readdirRecursive gets a gitIgnoreRoot option for this, and createSourceDeployArchive takes the project's directory in place of its unused targetSubDir parameter.

Scenarios Tested

• Unit tests: a parent .gitignore, a deeper .gitignore negation that overrides it, and a folder outside the root.
• Deployed an app in web/ with a web/public/*.pem file that only the top-level .gitignore ignores:
  • Before: the Cloud Run source deploy served the file publicly.
  • After: 404, like App Hosting and local builds. The uploaded files now match App Hosting's exactly, and every route matches the Cloud Run local build.

Sample Commands

# With "rootDir": "web" on the service in firebase.json:
firebase deploy --only run:web

[gemini-code-assist]

Code Review

This pull request adds support for applying parent .gitignore files when archiving directories for deployment (e.g., in App Hosting and Cloud Run). It introduces a gitIgnoreRoot option to fsAsync.readdirRecursive to traverse and stack .gitignore rules from parent directories up to the specified root. Feedback on the changes suggests wrapping the statSync check in parentGitIgnores with a try-catch block to prevent potential filesystem permission errors from crashing the directory traversal.

[gemini-code-assist]

Calling statSync(gitIgnorePath) directly can throw an error if there are permission issues (EACCES) or other filesystem restrictions on any of the parent directories, which would crash the entire directory traversal. Wrapping this check in a try-catch block ensures that any such filesystem errors are caught gracefully and logged as debug messages, allowing the traversal to continue safely.

    try {
      if (!existsSync(gitIgnorePath) || !statSync(gitIgnorePath).isFile()) {
        continue;
      }
    } catch (e: unknown) {
      logger.debug(`Error checking .gitignore file at ${gitIgnorePath}:`, e);
      continue;
    }

[falahat]

if we can not load the .gitignore for a project we should fail the deployment/build because it's unsafe to proceed. We might accidentally upload files the user doesnt want.