How to make the Jenkins agent build then start the server?

Question

I want the Jenkins agent to build and start the server.

I do this by specifying how to build and start the server in the Build step of the project configuration in Bash

echo "Installing dependencies"
npm install
echo "Starting server"
./startscript.sh 3000 & #this script will start the server with specified port

Why the ampsersand in /startscript.sh 3000 &?

I noticed that without the ampersand & in the last command, the server is started as expected (I can access it from browser). However, the Jenkins build hangs and cannot finish (because the script starts the server and won't return until the server is terminated).

So I tried to fix this with adding the ampersand to make the script process runs in background. With this, Jenkins job successfully ends the build.

But adding the ampersand still doesn't fix The server process is still terminated (it actually started because I checked the log and saw that it was started). I think that this might be because when Jenkins finishes building, it exits the shell and sends the SIGHUP to attached background jobs.

Adding nohub still doesn't fix

Running the last command with nohup ./startscript.sh 3000 & still doesn't fix the bug.

Question

How to make the agent build then start the server.

Note

The console output of Jenkins builds shows both the command and the output of it (like the behaviour of the -x flag of the shell). And the last command was shown like this:

+ nohup ./startscript.sh 3000
Finished: SUCCESS

It doesn't show the ampersand &... So I don't know if the ampersand was actually correctly interpreted during the run.

Answer 1

You are running into a conflict between jenkins nature of making sure everything is done before a job is complete and your desire for some long-running things to be asynchronous. There is no right answer here, both are reasonable desires, but you and jenkins are pulling in different directions. It may be ok for some parts of the jenkins job to not be completely done but they are good enough for the job. This is a decision you get to make.

If getting this working inside of jenkins is too much trouble there are work arounds. You can make your own daemon that looks for job completions (via files or database entries) and then starts something else. Obviously this means you lose the UX features of jenkins that let everybody know where something is. But you could make this work inside of jenkins by having different jobs also. The quick job finishes and then the longer job takes over. Since each is its own job it can have timeout requirements that make sense for it.