I have an existing nodejs app which i have pushed to the VSTS repository.
I have added three build tasks
npm install - running fine
Gulp - i have a gulpfile in which there is one task which executes "nodemon app.js" command, runs fine but this command starts listening the ports and hence the 3rd task which is the Web App task doesnt gets build. Until and unless Gulp task is built successfully, 3rd task wont get built. for eg "Express server started listening on port 1234" and then the gulp build task is still in running state due to which upfront task doesnt get started.
Some tasks, like nodemon start a background process and will watch the folder for changes. Normally you'd place these under the watch command, then implement a one-pass version of that in the build command.
As long as the Watch is running, control over the process isn't handed back to the Build agent and this will hang your build.
(Re)moving the commands that start watch/monitor processes so they won't get executed during a build is your best solution.
Related
(Note : my specific use case may seem complex, but the underlying idea is not!)
I have a Gulp script that starts a Docker container, which itself contains and starts another Gulp script that use Nodemon to start a final Node script in debug mode! The Nodemon Gulp script ran inside the Docker container looks something like this :
nodemon({
"script": `start.js`,
"nodeArgs": [`--debug=0.0.0.0:5858`, "-nolazy"],
"ext": "js",
"restartable": true
});
I'd like to be able to press [F5] in Visual Studio Code, have the final script started and have VSCode's debugger attached to it!
What does work :
If I start the first Gulp script manually, in a terminal, the Docker container is started, the other embedded Gulp script with Nodemon is executed and the final script is started. I can then press [F5] in VSCode to start an attach launch configuration and I'm able to debug! The port 5858 is exposed by Docker and everything runs fine.
What I want :
I want to be able to skip the manual launching of the script in a terminal. I want a VSCode launch configuration that does everything by itself => launch the script in VSCode's integrated terminal and attach a debugger to the debug process started by the script itself.
I tried :
An "request": "attach" launch configuration with a preLaunchTask task. That task is launching the first Gulp script. The problem with this approach is that the preLaunchTask task never ends : it starts the first script in the terminal (The task has a : ""_runner": "terminal"") but in the end the final script is listening and doesn't exit (it's actually listening for requests)... This seems to prevent the VSCode debugger to start because the preLaunchTask task never exit.
A "request": "launch" launch configuration that starts the first script. But here, even if it looks like it is going to work (the orange debugging bar appears), the debugging never actually work. If I understand correctly, this is because a launch launch configuration starts a Node debugger by itself (on the specified port) and therefore the debugger starts by Nodemon, inside the Docker container, will never be listened to.
In other words : I simply want to hit [F5] so a script is launched in the integrated terminal, without debugger, and then VSCode will attach a debugger to the resulting 127.0.0.1:5858 debug process, wathever how this process is actually started.
UPDATE : I also had a suggestion on Github about trying to use a compound launch configuration, but it also doesn't work: https://github.com/Microsoft/vscode/issues/36685
Your first try, an attach config with a preLaunchTask is correct. You probably just need one adjustment. By default, vscode will be waiting for the task to terminate, so you need to tell it that the task will run in the background, by adding "isBackground": true. Then you need to tell it which patterns to watch for in the task's output to know when the task is complete. This bit is a little annoying, because you have to do this with a problemMatcher, but this task should not contribute problems, so you need to give it a regex that won't match anything. e.g.:
"problemMatcher": {
"pattern": {
"regexp": "__________"
},
"background": {
"activeOnStart": false,
"beginsPattern": "Some pattern when the debugging process is about to start",
"endsPattern": "Ready for attach"
}
}
The task runner is watching the program output to match endsPattern - when some output matches, then it will know the program is ready for the debugger to attach. If your script isn't producing any output, you should add some console.log after invoking nodemon.
Usually the problemMatcher is for matching problems output by the build task, and the regex can match the filename, line, and error message. But here we are just using it for the "background" patterns, so we give it a dummy regex. Here's a thread describing this workaround and how it could be easier in the future by moving the "background" patterns out of the patternMatcher:
https://github.com/Microsoft/vscode/issues/6209#issuecomment-289411630
And here is the documentation on watching tasks, for more details: https://code.visualstudio.com/docs/editor/tasks#_background-watching-tasks
I have edited the startup-script variable for one of my instances running on the Google Cloud Platform App Engine. I'd like it to call a forever script to make sure my node app is running. So I added:
cd /opt/bitnami/apps/myapp
forever start --workingDir /opt/bitnami/apps/myapp/ --sourceDir /opt
/bitnami/apps/myapp/ app.js
after the #!/bin/bash line (also tried without the cd as it's not really necessary based on my command). But once the vm is started, running a forever list doesn't list my forever task as having ever started. If I copy and paste that forever command into a gcloud terminal and run, the task shows up fine and my app starts no problem.
Am I not calling this correctly somehow within the bash script?
The simple answer is that GAE does this by default. No need for forever or PM2. There are certain health checks that GAE does on the Docker container holding your app, and if they do not pass the instance is automatically restarted
If you want granular control over these checks (called Legacy Health Checks) you can add this to your app.yaml file:
health_check:
enable_health_check: True
check_interval_sec: 5
timeout_sec: 4
unhealthy_threshold: 2
healthy_threshold: 2
There is also updated mechanisms (called Updated Health Checks) that are still in beta, but can be used instead
The proper way to start your nodejs app on appengine is to specify the "scripts" field in your package.json, as the documentation
Below is an example borrowed from this sample
"scripts": {
"start": "node ./bin/www",
"test": "cd ..; npm run t -- appengine/analytics/test/*.test.js"
},
If you however, are only interested in running a node script, and not interested in the features that come with Google app engine, then you may simply run it on a Google Compute Engine instance.
I want to run the exact same grunt watch task in production mode that's run in development mode. I thought it would be as simple as adding the watch task to the "prod.js" task in tasks/register/prod.js, but doing that hangs Sails upon lift.
How do I run the watch task in production?
How do I run the watch task in production?
I have found out recently that sails (v.0.11.0) restricts grunt executions in production mode before startup. To fix this problem, you need to change a few lines in /node_modules/sails/lib/hooks/grunt/index.js
Specifically, comment the lines:
// Fire finish after grunt is done in production
/*if(sails.config.environment === 'production'){
cb_afterTaskStarted();
}*/
comment and add:
// Go ahead and get out of here, since Grunt might sit there backgrounded
/*if(sails.config.environment !== 'production'){
cb_afterTaskStarted();
}*/
cb_afterTaskStarted();
In the JHipster gulpfile.js, there is a watch task set up for JS files which attempts to call a 'browserify' task. However, there is no 'browserify' task defined. If you are running 'gulp server' during development, the process will terminate as soon as you modify one of your JS files.
[11:43:19] Server started
[11:43:19] LiveReload started on port 35729
[11:43:19] Finished 'server' after 52 ms
**[11:52:14] Task 'browserify' is not in your gulpfile**
[11:52:14] Please check the documentation for proper gulpfile formatting
Is this a bug? I don't see why we would need to call to browserify with the current setup.
Yes it looks like a bug:https://github.com/jhipster/generator-jhipster/issues/367
The Gulp option is a community effort, and is less stable than the Grunt option.
However, of course, our goal is to have a correct and stable Gulp option for our soon-to-be-released 1.0 version.
Can you add your comments and feedback to the opened bug?
I'm using gulp and running nodemon from a task. Everytime it detects changes it
restarts the server
runs "build" task
Yup in that order. Couldn't figure out how to kick "build" task before nodemon's restart happens (setting delay param didn't help).
nodemon = require "gulp-nodemon"
runSequence = require 'run-sequence' # couldn't figure out how to run gulp task
# from another task, so ended up using this
nodemon(
script:'server.js'
watch: 'src/**/*.*'
).on "restart" (files)->
runSequence "build"
Now, my problem is - when something happens during build, something that I apparently can't really control (let's say Jade files fail to compile), process throws uncaughtException and crashes. What I need though, to restart nodemon, and keep trying building until failing jade file fixed.
I've tried running "build", followed with nodemon in process.on 'uncaughtException', it kinda works, but then nodemon stops watching files and can't recognize changes anymore.
Can you guys advise.