Why does my script fail after I finish building

This is a Node project, I add & build after the startup command, the build is done, but I can’t access it
微信图片_20211022170013
When I remove the &, the build is always running, but I can access the project

  • I really want to know what’s going on here

I believe jenkins will kill all processes associated with it once the job is done to do cleanup. You’d have to fully detach your process for it to survive after the job is run. You can probably use nohup, screen or tmux for that. I don’t recommend this approach though as next run won’t have a clean setup and likely have port conflicts.

If your trying to do a deploy I’d look into actual deployment systems (docker, ssh, capistrano, etc). Looks like shipit might be a node version of capistrano - How To Automate Your Node.js Production Deployments with Shipit on CentOS 7 | DigitalOcean

For the future, make sure you include context about what your doing, a general rule is:

  1. What are you trying to do?
  2. What did you expect to happen?
  3. What did happen?

You sorta covered 2 and 3, but without context, I had to guess what you meant.

Actually, I want to access my project after the successful build, this is the script I wrote initially, it was successfully built, but I failed to access the project, I want to know the reason, if it is because Jenkins killed my project service after the successful build, I want to know how to avoid it, thank you :grinning:

like i said, jenkins isn’t designed to keep things running. You’ll have to detach your process from your jenkins shell using nohup, tmux or screen. Or use a tool designed for deploying.

@halkeye is right. Jenkins works very hard not to leak resources. It must work very hard to no leak resources or it will exhaust resources from running for long periods of time. Starting a process inside a Jenkins job is very common and if Jenkins does not actively work to stop processes that have been started by a Jenkins job, the leaked processes could easily overwhelm the system.

Deploy to a location that is outside the control of Jenkins. Even techniques like nohup, tmux, and screen tend to be reaped by the Jenkins process. Deploying to a web server that is running as a separately managed service will allow you to control the start and stop of that service separate from Jenkins.