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

Deployed application uses wrong index.html file #2

Closed
ngEdmundas opened this issue Jan 18, 2014 · 6 comments
Closed

Deployed application uses wrong index.html file #2

ngEdmundas opened this issue Jan 18, 2014 · 6 comments

Comments

@ngEdmundas
Copy link

@ngEdmundas ngEdmundas commented Jan 18, 2014

In our app the public directory specified in firebase.json contains several HTML files. The main is called "index.html", the others are "index-full.html" and "facebook-channel.html". After "firebase deploy" the "index-full.html" becomes the default index file and following URLs all load contents of the same file "index-full.html":

If "index-full.html" was renamed to "index-full.html-off", then the correct "index.html" is picked up as the default index file.

@cbraynor
Copy link
Contributor

@cbraynor cbraynor commented Jan 20, 2014

I'm afraid this has to do with the post-processing the provider we're using to prototype this beta does on the files uploaded. We're working on removing this feature soon, or at the very least allowing you to disable it.

Thanks for your patience

@ngEdmundas
Copy link
Author

@ngEdmundas ngEdmundas commented Jan 20, 2014

Thanks for response, Firebase hosting is a great service and it was easy to work around these small deployment glitches.

@cbraynor
Copy link
Contributor

@cbraynor cbraynor commented Feb 4, 2014

This should now be fixed. Thanks for the interest

@azucenareyes
Copy link

@azucenareyes azucenareyes commented Mar 28, 2018

Hello,
I cannot deploy my web app, well it says deployed but I don't see my app. I just see the standard index.html Welcome page. Do I need to create my own index.html page? I am using create-react-app.
Thank you

@bhimbolar
Copy link

@bhimbolar bhimbolar commented May 27, 2018

@azucenareyes Check your firebase.json file Edit the line "public": "public" to "public": "app", or any other directory where your app content resides. That will help you.

@MrAndrew
Copy link

@MrAndrew MrAndrew commented Nov 11, 2018

The problem is when firebase is creating the index file, it overwrites the one created by react. So what you have to do is run all the firebase code (minus deploy), then rerun 'npm run build' to get react to recreate the index file you need in the build directory, then change the firebase.json "hosting" block's "public" key to "build". (Specifically for react, as that is the default dir for it.) Finally you can deploy it and all should be right. (Except for how much manual effort that takes.)

inlined added a commit that referenced this issue Jul 3, 2021
The primary purpose of this change is to introduce the "discovery"
subpackage of "runtimes". This package is a common utility that all
runtimes will use to discover their backend spec based on the "container
contract" being finalized currently.

The container contract says that we must interact with customer code
using tools we'd have in a docker container: a fully-contained directory
of code, a "run" command, and environment variables. Backend specs can
be discovered as:

1. The file /backend.yaml at the root of the container
2. The response to http://localhost:${ADMIN_PORT}/backend.yaml when
   running the container's RUN command with ADMIN_PORT set to a free
   port.

The golang runtime fulfills #2 through two steps:

1. The Functions SDK includes the "codegen" package that reads the
   customer code and creates an "autogen" main package that runs
   the customer code as the Firebase runtime (skeleton implementation
   currently).
2. We then start up the Firebase runtime with ADMIN_PORT set and
   fetch /backend.yaml

After this + a minor fix to the template code, we have working Go
deploys!

I also moved gomod parsing into its own file to keep index.ts to a
minimal set of things that aren't easily unit tested. Unfortunately
the diff is largr than it needs to be now.
inlined added a commit that referenced this issue Jul 12, 2021
* Further improve function initialization

The primary purpose of this change is to introduce the "discovery"
subpackage of "runtimes". This package is a common utility that all
runtimes will use to discover their backend spec based on the "container
contract" being finalized currently.

The container contract says that we must interact with customer code
using tools we'd have in a docker container: a fully-contained directory
of code, a "run" command, and environment variables. Backend specs can
be discovered as:

1. The file /backend.yaml at the root of the container
2. The response to http://localhost:${ADMIN_PORT}/backend.yaml when
   running the container's RUN command with ADMIN_PORT set to a free
   port.

The golang runtime fulfills #2 through two steps:

1. The Functions SDK includes the "codegen" package that reads the
   customer code and creates an "autogen" main package that runs
   the customer code as the Firebase runtime (skeleton implementation
   currently).
2. We then start up the Firebase runtime with ADMIN_PORT set and
   fetch /backend.yaml

After this + a minor fix to the template code, we have working Go
deploys!

I also moved gomod parsing into its own file to keep index.ts to a
minimal set of things that aren't easily unit tested. Unfortunately
the diff is largr than it needs to be now.

* PR feedback
devpeerapong added a commit to devpeerapong/firebase-tools that referenced this issue Dec 14, 2021
* Further improve function initialization

The primary purpose of this change is to introduce the "discovery"
subpackage of "runtimes". This package is a common utility that all
runtimes will use to discover their backend spec based on the "container
contract" being finalized currently.

The container contract says that we must interact with customer code
using tools we'd have in a docker container: a fully-contained directory
of code, a "run" command, and environment variables. Backend specs can
be discovered as:

1. The file /backend.yaml at the root of the container
2. The response to http://localhost:${ADMIN_PORT}/backend.yaml when
   running the container's RUN command with ADMIN_PORT set to a free
   port.

The golang runtime fulfills firebase#2 through two steps:

1. The Functions SDK includes the "codegen" package that reads the
   customer code and creates an "autogen" main package that runs
   the customer code as the Firebase runtime (skeleton implementation
   currently).
2. We then start up the Firebase runtime with ADMIN_PORT set and
   fetch /backend.yaml

After this + a minor fix to the template code, we have working Go
deploys!

I also moved gomod parsing into its own file to keep index.ts to a
minimal set of things that aren't easily unit tested. Unfortunately
the diff is largr than it needs to be now.

* PR feedback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants