I followed the contents of three different tutorials in deploying a slightly-modified boilerplate React app to Azure App Services. The primary issue I'm having is that while all deployment pipelines and releases have been successful on Azure DevOps, navigating to the page results in the default landing page for non-deployed app services;
Hey, Node developers!
Your app service is up and running.
Time to take the next step and deploy your code.
I'll briefly describe the steps I took to get to this point:
I used create-react-app to generate a basic template, ran all the prerequisite commands, fiddled with the app.js file and its CSS companion, and left index.* untouched.
I pushed all of it with an untouched gitignore to a Github repository.
I created an App Service, running Linux and Node 12 LTS, on the Free plan.
I created a DevOps project, and within it created a Pipeline and a Release Pipeline.
In the Pipeline: I retrieved my repository source via linked accounts in the Get Sources step. In Agent job 1, I added a npm install element, a npm run build element, and a Publish Artifact element. I set the path to build, and artifact name to artifact, publishing to Azure Pipelines.
In the Release Pipeline: I added an artifact that grabs its source from the previous pipeline, and gives a source alias of _artifact. CD trigger is enabled. I added a stage that has a Deploy Azure App Service element, using $(System.DefaultWorkingDirectory)/_artifact/artifact as the package/folder.
When I push a commit or manually trigger the first pipeline, everything succeeds with no obvious errors. The Release pipeline is triggered and also completes without error. Checking the logs, the artifact is stored and accessed accurately. I can see the correct build files being accessed.
In the Azure portal, I can see that deployment has succeeded with the correct timestamp, commit name, and pipelines. However, when I access the actual site, I am shown the generic page.
Am I missing a crucial step somewhere? I've tried navigating to /index.html, /src/index.html, and a bunch of other combinations of known files, but to no avail; Cannot GET /index.html.
Any insight would be appreciated.
For reference, I used these three walkthroughs:
https://medium.com/microsoftazure/deploying-create-react-app-as-a-static-site-on-azure-dd1330b215a5
https://medium.com/#to_pe/deploying-create-react-app-on-microsoft-azure-c0f6686a4321
https://www.pluralsight.com/guides/deploy-a-react-app-to-azure
This question is very simple, you can refer to the following post.
1. Deploy create-react-app with azure pipelines
2. Unable to deploy React JS application on Azure App service
3. Process for React App deployment to Azure Web?
Suggestion:
It is recommended to choose linux when creating a webapp.
Configuration->StartupCommand: pm2 serve /home/site/wwwroot --no-daemon --spa
Related
I know two ways of hosting an app.
You either go to settings and set source branch and select folder.
You can follow some steps like npm --save install gh-pages, npm run deploy and so on.
I tried to host my app the 1st way, but it shows README file and it doesn't show index.html in public folder.
The "Configuring a publishing source for your GitHub Pages site" does mention choosing a branch and folder.
But:
gh-pages is always a branch, not a folder.
the folder referenced in the documentation seems only to be /docs: try for testing your index.html in docs/ rather than public/.
That being said, try and test the new (Dec. 2021) feature:
GitHub Pages: using GitHub Actions for builds and deployments for public repositories
Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories.
This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository.
As the name suggests, it builds and deploys your pages site.
The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users.
However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.
You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages.
For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.
Learn more about GitHub Pages
I am using Google Cloud to deploy my application. I have followed the steps in the documentation for deploying. I deployed early on in my project and it was successful. I then decided to change some files and update some features in my app. For this i followed the documentation for updating a deployment. This update was successful. It had me create the deployment in my Deployment Manager and run the gcloud commands to commence update. When I redeployed with gcloud app deploy, it was successful.
I have since added a couple more lines of code and features in my application. I followed the same documentation for updating a deployment as I had the first time I made an update and it is no longer working for me.
Does anybody have any idea what would be the problem? Again, I was able to successfully deploy, and even update that deployment once by following Google Cloud docs. Now I am having no luck.
Have you been changing the version number? Go to:
https://console.cloud.google.com/appengine/versions?project=< your project name >&serviceId=default
And make sure the version you want is active. Also, you can try:
http://<VERSION>-dot-<SERVICE>-dot-<PROJECT_ID>.<REGION_ID>.r.appspot.com
Example:
https://20200813-dot-myapp.uc.r.appspot.com
if the version number was 20200813 and your appname is myapp and the region is uc
I am currently trying to deploy the default react web app to Azure and I am encountering an issue where though I deploy the contents of my build folder to the azure hosted /site/wwwroot folder I end up on the following page when going to my hosted address: https://[project_name].azurewebsites.net/
Landing Page :
I intend to deploy the default create-react-app react application so that I may have the process down for when I deploy my real site.
The process I have followed is pretty much exactly what is mentioned in this article https://medium.com/#to_pe/deploying-create-react-app-on-microsoft-azure-c0f6686a4321
Create the default React App with create-react-app
Run "npm run build" to get the build folder
Go into the Azure React Portal and create a new Web App ***
FTP / Git deploy the contents of the local build folder into the Azure website's /site/wwwroot/ folder
For overkill I added the below web.config file to handle future routes, but have also tried without this step
In the end my Azure site's contents look like this
Folder contents :
At this point when I try to access the Azure site I get the "Hey, Node developers!" page which implies my code is not deployed. Any thoughts as to why this might be the case?
*** I have a hunch that during the configuring of the Azure Web Api something is not set up correctly perhaps because I select Node 10.14 as my Runtime stack simply because that is the version of Node that I have installed and am using with my local React app.
Thank you folks for your time.
Another approach is to configure Azure Linux Web App Service to run a startup command to serve your React app in "Settings > General settings > Startup Command":
pm2 serve /home/site/wwwroot/ --no-daemon
Remember to change the path to your build path (The path to your index.html file).
If you use react-router and wants to make any direct access on custom routes be handled by index.html you need to add --spa option on the same command.
pm2 serve /home/site/wwwroot/ --no-daemon --spa
Using --spa option pm2 will automatically redirect all queries to the index.html and then react router will do its magic.
You can find more information about it in pm2 documentation: https://pm2.keymetrics.io/docs/usage/pm2-doc-single-page/#serving-spa-redirect-all-to-indexhtml
I've coped with the same problem recently: React router direct links not working on Azure Web App Linux
You have created a Linux App Service - your web.config won't work because there is no IIS.
If you don't select node as the runtime stack, your app will work for the most part because it serves the files like a static web host. However I would suggest to keep the runtime stack as node and add the following file to your deployment in the wwwroot folder:
ecosystem.config.js
module.exports = {
apps: [
{
script: "npx serve -s"
}
]
};
https://burkeknowswords.com/this-is-how-to-easily-deploy-a-static-site-to-azure-96c77f0301ff
There's an extremely simple way to overcome this problem, and although it is not perfect, it works both on AWS, Microsoft Azure, and probably any other hosting:
Just point the error document to: index.html
I found it out here:
https://stackoverflow.com/a/52343542/3231884
Disclaimer: This solution is not perfect and impacts SEO. Google doesn't rank well sites that throw 404s.
We are building an application that so far has a simple user management implementation. This question relates to the built-in password resetting functionality of Loopback v3. User management is being worked on a model derived from the built-in User, and it is called MyCustomUser
Each time code changes are pushed into a GitHub repo, we have Jenkins build a Docker container, and inside of it run npm install then lb-sdk (with suitable parameters) then ng build --env=prod and finally node .. After this happens, the application runs normally, BUT:
When performing the same deployment commands locally (on my own linux laptop), the API endpoints /MyCustomUsers/reset and /MyCustomUsers/reset-password are created (i.e. they are visible and manipulable via the Strongloop Explorer)
When the deployment is run by Jenkins in the Docker container, only one of the two API endpoints is created, /MyCustomUsers/reset. God only knows where the other endpoint, /MyCustomUsers/reset-password, ends up.
Obviously, all deployments are run against the same codebase (i.e. the same commit ID of the GitHub repo). It is bewildering how the service behaves perfectly on localhost but not on the cloud-based docker container.
Sounds like you are running two different versions of the Loopback-Angular2-SDK. From what I've understood the SDK for Angular2 is still in heavy beta and not yet ready for production. However this doesn't excuse the difference, but it really sounds like two different versions.
We are using the same build-flow as you, are your package.json identical when it comes to #mean-expert/loopback-sdk-builder?
The guys working with the SDK-generator are really good at responding in their issue-section, would recommend asking there otherwise.
It turns out that the remote docker was running node 6.9.2 and npm 3.10.9, whereas I was running node 6.10.3 and npm 3.10.10. After making the docker instance run the same versions as I had locally and deploying the package.json along with its npm-shrinkwrap.json, the endpoint was correctly generated.
I cannot get my server code to update. I'm running a PHP instance on GAE and no matter what I do, the files won't update. In the source code view, I can see the files have updated, but when I attempt to access the updated file, I'm still viewing the old version. I've also attempted disconnecting my Bitbucket repo and using the appcfg.py update project-name command, but the files aren't refreshing when I attempt to access them. I'm not sure what to do to force the changes to take place.
My app.yaml contains the following code
- url: /(.+\.php)$
script: \1
secure: always
So the files should be getting read, right?
I was able to figure out what went wrong. I downloaded my code using appcfg.py download_app -A <your_app_id> -V <your_app_version> <output-dir> and noticed that I was downloading the old versions of the files (and wasn't downloading the new files). Turns out using source control within GAE will upload new code, but won't deploy it. I attempted to use appcfg.py update project-name one more time, but it didn't work. Turns out I didn't disconnect my Bitbucket account (could have sworn that I did...). Once disconnected, I was able to update the project using appcfg.py update project-name. While I was figuring this out, I reached out to Google support and received this message:
To use the feature of push to deploy you need to spin-up the Jenkins
Instance on GCE (Google Compute Engine) and then it will take the
updated code and execute it in the environment. Go through [1] for how
to enable the Jenkins instance and its configuration according to
different run time.
In your issue, you just mirrored the code from Bit Bucket to Cloud
Repository, as it is just doing the version control for the
application not executing the application. So basically you have have
the option of using Jenkins instance as I described above to test the
different version of the code or using the appcfg.py update command
from your local repository.
I haven't attempted to install and use Jenkins since I fixed it after disconnecting my Bitbucket account), but it may help others who have run into this problem.