I am attempting to build a jhipster application for production with the following command:
./mvnw -Pprod package
According to the documentation here https://jhipster.github.io/profiles/ the war file should automatically run with the active spring profile "prod" when it is kicked off. However, I'm finding that is runs with the defaults of swagger,dev.
Am I missing something here? If I set --spring.profiles.active=prod when running the build war file the correct profile is activated but according to the documentation, prod should be activated by default based on the way I built it.
Any ideas?
Related
I'm trying to set up CI/CD with Azure pipelines to automatically deploy a frontend vue application, but am having trouble with deploying my frontend application from it.
When deploying manually from the VS Code IDE it works fine, with the /home/site/wwwroot looking as expected in the kudu file explorer:
However when it's deploying from Azure Pipelines, it seems that the zip file remains zipped and is stored in another directory within /home/site/wwwroot/Package (e.g /home/site/wwwroot/Client/.zip), resulting in the application being unable to
This is what it looks like in the kudu powershell debugger:
My pipeline and release is pretty standard. The steps are:
Uses Node 16.x
Downloads a .env file
Copies the .env file to the directory (/client) the application is in.
runs npm install
runs npm run build
archives the dist directory that is generated from the run build command
Publishes the archived dist folder as an artifact
An Azure release is then created and deploys the artifact to the correct Azure App Service. Currently the deployment method is set to default, although I have tried each of the different deployment methods (Web deploy, Zip deploy, and Run from package) but none have worked so far.
I've downloaded the resulting zip file from the pipeline deployment, unzipped and manually deployed (using VS Code) the dist folder within which was successful, so I'm quite sure that the pipeline part of the process which installs, builds, and packages the application is working as expected, but something is going wrong during deployment.
If anyone has any ideas of what the error may be, or is able to offer any help/sugestions, it would be greatly appreciated.
Thank you.
Ensure that the archive job option for "prepend root folder name to archive paths" is disabled in the pipeline.
Also ensure the Package or folder route in the release's deploy job is correct. It should be something like:
$(System.DefaultWorkingDirectory)/______ClientPipeline/ArtifactName/*zip
Suppose I modified the source code of generator-jhipster repo and I would like to generate my "custom" JHipster application into a specific directory, how would I accomplish this task?
After installing JHipster:
npm install -g generator-jhipster
I would be able to generate the application with:
jhipster
However, this command runs the application directly from the JHipster repository.
Since I modified the source code, I could generate the application locally by running:
node jhipster.js
in the ../cli directory.
The problem is, running this command in cli directory will generate the application in the same directory (cli) and this is not what I want.
I need to find a way to export the application into a specific directory.
Note: I strongly believe this has something to do with process.cwd(), because that generates the application in the local directory, but I'm not sure exactly
which source file to modify as I don't want to break anything.
I am trying to deploy a react based app in jetty. As part of that, I thought of trying to do the same in jetty server.
I followed a link:
https://www.megadix.it/blog/create-react-app-servlet/
The above link explains details about it and at the end there is a github project for making a war. the link to that is below:
https://github.com/megadix/create-react-app-servlet
Now, I am able to deploy the war created using the above github project in tomcat 9. I am unable to understand how the dependency resolution of node_modules is happening. Also I am unable to deploy the same war in jetty(putting the war in webapps folder and starting jetty)
Thanks
Single page applications needs to be compiled into one (in same cases more) .js file. In your case, create-react-app or similar tools are responsible for fulfilling this requirement.
In the pom.xml execution list, you can see npm install, npm build commands. They are pretty much similar as mvn clean install and mvn buuild.
Dependencies are resolved from package.json dependencies field and installed under node_modules. Once dependencies are there, npm build (or create-react-app-servlet build), compiles all the source code + dependencies into a js file. This probably has a name like main.XXXXXX.js.
In the end, you have a dist folder consisting of .html, .js and other resources.
It'd be better if you share more details of what's happening with jetty deployment
I'm creating a vanilla Angular project and uploading it to Bitbucket. It runs locally and I can build it into dist with no errors nor warnings. Now, I'd like to expose it on my Azure account. There's quite a lot of material showing how to but most of it is a bit aged (the options in Azure has changed) and/or the authors make it easy and use another options for the source (I target specifically Bitbucket).
Optimally, I'd like the following to happen.
Trigger by a push, get the files from the BitBucket repo.
Execute the command ng build --prod (or npm run build).
Copy over the artifacts from dist to the root of the app.
Checking the logs, I see two sections of relevance. First one is Generating deployment script, while the second is Running deployment command. The end of those as well as the label in the portal imply that it's all good and dandy. Well, it's not.
Using the following command to generate deployment script: 'azure site deploymentscript -y --no-dot-deployment -r "D:\home\site\repository" -o "D:\home\site\deployments\tools" --node --sitePath "D:\home\site\repository"'.
Generating deployment script for node.js Web Site
Generated deployment script files
Command: "D:\home\site\deployments\tools\deploy.cmd"
Handling node.js deployment.
KuduSync.NET from: 'D:\home\site\repository' to: 'D:\home\site\wwwroot'
Deleting file: 'hostingstart.html'
Copying file: '.angular-cli.json'
Copying file: '.editorconfig'
...
Copying file: 'src\index.html'
Copying file: 'src\assets\logo.png'
Copying file: 'src\assets_favicon.ico'
Copying file: 'src\environments\environment.prod.ts'
Copying file: 'src\environments\environment.ts'
Invalid start-up command "ng serve" in package.json. Please use the format "node ".
Looking for app.js/server.js under site root.
Missing server.js/app.js files, web.config is not generated
The package.json file does not specify node.js engine version constraints.
The node.js application will run with the default node.js version 6.9.1.
Selected npm version 3.10.8
web#0.0.0 D:\home\site\wwwroot
+-- #angular/animations#5.2.9
...
`-- zone.js#0.8.26
Finished successfully.
However, when I access the page, only the default document provided by MS shows. I've tried accessing the image files but failed (not sure if I got the link wrong or if those aren't there). All in all, I feel that I'm barking up the wrong tree. Trying to repeat the steps (possibly with slight changes), produced a website that says You do not have permission to view this directory or page, which gets me to a confused position where I see no rational next step in troubleshooting.
Suggestions on what I might be missing?
We are currently trying to setup an Angular 2 project that also contains a Cloud Service project in its solution. We have set up numerous Angular 1 projects containing Cloud Service projects and have had no errors. When trying to run the MSBuild step for the Angular 2 project, we get the following error on the TeamCity build server:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure Tools\2.7\Microsoft.WindowsAzure.targets(2787, 5): error MSB3021: Unable to copy file "C:\TeamCityBuildAgent\temp\buildTmp\.NETFramework,Version=v4.6.1.AssemblyAttributes.cs" to "C:\SourceControlFolder\Apps\MyApp\MyApp.CloudDeployment\obj\Debug\Website\C:\TeamCityBuildAgent\temp\buildTmp\.NETFramework,Version=v4.6.1.AssemblyAttributes.cs". The given path's format is not supported.
The main problem seems to be the build attempting to throw the full C:\TeamCityBuildAgent.. path into the obj\Debug\Website folder.
My current MSBuild parameters are:
/p:Configuration="Dev"
/p:platform="Any CPU"
/p:OctoPackEnforceAddingFiles=true
/p:OctoPackProjectName=MyApp_Dev
I've tried the following solutions:
Making sure the latest Visual Studio Update is installed (for MSBuild)
Running the install tool to repair Azure Tools 2.7 on the build server.
Changing the debug configuration in the build.
Ensuring TypeScript 1.7.6 is installed on the build server (even though it's an Azure.targets issue) [https://github.com/Microsoft/TypeScript/issues/6215]
Updated the project to Azure Tools 2.9. The same error remains except it's failing on the 2.9 folder instead now.
Curious if anyone else has experienced this error and knows a fix. I'll keep this post updated as I try other solutions.
Update
It appears that what is causing this issue is this line within the .csproj file:
<FilesToIncludeForPublish>AllFilesInProjectFolder</FilesToIncludeForPublish>
This is specified for our build configurations to copy all files generated by the ng build to the output directory of the publish. What I don't understand at the moment is how this works on all of the devs' local machines but does not work on our build server. Will keep this posted as I find more info or any kind of workaround.
This ended up being the fix:
Instead of targeting the .sln in MSBuild, we specifically targeted the .csproj file. This fixed the build errors and allowed us to keep the FilesToIncludeForPublish tag inside.