You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
hosting:clone no longer finds a source site in another project (15.33.0) #11247
The live version of site-a is cloned to site-b:live, as in 15.31.0 and earlier. Site IDs are unique across all projects, so the CLI could find site-a without being told its project.
[REQUIRED] Actual behavior
GET https://firebasehosting.googleapis.com/v1beta1/projects/project-b/sites/site-a/channels/live 404
{"error":{"code":404,"message":"site `site-a` was not found on project `project-b`","status":"NOT_FOUND"}}
Error: Could not find the channel live for site site-a.
This seems to come from #11229, which replaced the - project wildcard with explicit project IDs. Now the source project defaults to --project. Writing the source as project-a:site-a:live works on 15.33.0, but 15.31.0 can't read that form. So a script can't support both versions, and existing cross-project hosting:clone scripts broke in a minor release.
Could you either:
look up the source site with the - wildcard when the source has no project, as before, or
mark this as a breaking change in the changelog and the hosting:clone help text, and have the error suggest the project:site:channel form when the site exists in another project?
Thanks for the thorough report @sebr! I am able to reproduce the issue. I'll check this with our engineering team to see if we can restore the old behavior or update the release notes and add an clear error suggesting the new format(<project>:<site>:<channel>) when the source/target site is on another project.
ah - sorry, I didn't quite realize that this ends up breaking things so drastically. I'm going to attempt to un-breaking-change this so that the project ID isn't absolutely required (but it should still use the project ID in the API calls that it makes).
Activity
aalej commentedon Oct 8, 2026
Thanks for the thorough report @sebr! I am able to reproduce the issue. I'll check this with our engineering team to see if we can restore the old behavior or update the release notes and add an clear error suggesting the new format(
<project>:<site>:<channel>) when the source/target site is on another project.mcve - https://github.com/aalej/issues-11247
bkendall commentedon Oct 13, 2026
ah - sorry, I didn't quite realize that this ends up breaking things so drastically. I'm going to attempt to un-breaking-change this so that the project ID isn't absolutely required (but it should still use the project ID in the API calls that it makes).
fix(hosting): implicitly resolve site project IDs in hosting:clone
fix(hosting): implicitly resolve site project IDs in hosting:clone (f…