Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hosting deploy wrongly assumes all-or-none webframeworks #8168

Open
fivecar opened this issue Feb 5, 2025 · 2 comments · May be fixed by #8169
Open

Hosting deploy wrongly assumes all-or-none webframeworks #8168

fivecar opened this issue Feb 5, 2025 · 2 comments · May be fixed by #8169

Comments

@fivecar
Copy link

fivecar commented Feb 5, 2025

Environment info

firebase-tools:
13.30.0

Platform:
Ubuntu

Test case

  1. Create a firebase.json with two hosting targets: one using webframeworks and one normal (i.e. "target: framey" with source and "target: classic" with public).
  2. Attempt firebase deploy --only hosting:classic

Steps to reproduce

(same as test case above)

Expected behavior

Deploy of "classic" target to succeed. Of course a deploy of hosting:framey should fail... but I wouldn't expect classic to fail because it doesn't use webframeworks.

Actual behavior

Deployment errors out with "Cannot deploy a web framework from source because the experiment webframeworks is not enabled. To enable webframeworks run firebase experiments:enable webframeworks."

I suspect this line is the problem. The tools shouldn't be asserting webframeworks whenever any target requires it... it should only be asserting it for the specific target if it uses it.

fivecar added a commit to fivecar/firebase-tools that referenced this issue Feb 5, 2025
In deployments where `--only hosting:boo` is used, enforce webframeworks
enablement only when the target actually uses webframeworks.
@fivecar fivecar linked a pull request Feb 5, 2025 that will close this issue
@aalej
Copy link
Contributor

aalej commented Feb 6, 2025

Thanks for the detailed report and for submitting a PR @fivecar! I’m able to reproduce the error you mentioned. I do think that this behavior can be improved by only asserting webframeworks to be enabled if the target requires it(uses hosting.source).

Let me ask someone from our engineering team to take a look into this.

@fivecar
Copy link
Author

fivecar commented Feb 6, 2025

@aalej : I've already attached a PR that fixes it (#8169). So this only needs the eng team to approve the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants