Starting local HTTP server in background causes GoCD to be stuck

172 views
Skip to first unread message

Martin Burger

unread,
Jan 13, 2022, 2:33:56 PM1/13/22
to go-cd
Hello:

I am using GoCD for continuously deploying some websites and web applications, respectively. Those websites and web apps are build with Snowpack, a frontend build tool which uses Node.js / npm.

As part of the whole build and deployment process, I run a local HTTP server using npm package http-server. That server serves the built app from the local project folder. Then, using that local web server, a series of playwright tests is run to conduct various end-to-end tests in different rendering engines like Chromium. That way, I can run some quick smoke tests locally before the whole app will be deployed to a remote server. There, more elaborate tests are run.

On my local machine, that works like a charm. However, when GoCD executes the built process, it gets stuck when launching the web server.

Basically, the web server is launched in package.json via "http-server ./build -a 127.0.0.1 -p 8181 &". Then, the playwright tests are run. At the end, I use "kill $(lsof -t -i:8181)" to stop the server.

However, GoCD gets stuck when trying to launch the web server. I assume that has something to do with trying to run the web server in the background (note the ampersand at the end of the command).

How can I run that build process using GoCD?

Best wishes,

Martin

Chad Wilson

unread,
Jan 14, 2022, 11:05:43 AM1/14/22
to go...@googlegroups.com
Are these individual steps in separate GoCD "command" tasks within a single job? Can you share what your job definition looks like?

-Chad

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/3b61c1c3-c819-4ff4-a0c7-15cf65b6ace1n%40googlegroups.com.

Martin Burger

unread,
Jan 15, 2022, 2:51:11 PM1/15/22
to go-cd
Hey Chad:

Thanks for your help. To run the smoke tests is an individual step and task, respectively. More precisely, it's a custom command that runs `npm run test:smoke:build`:

Screen Shot 2022-01-15 at 20.32.10.png
That's the expected output as captured on the console at my local machine:

❯ DEPLOY_TARGET=preview npm run test:smoke:build

> test:smoke:build
> run-s --continue-on-error test:smoke:build:startserver test:smoke:build:run test:smoke:build:stopserver


> test:smoke:build:startserver

> http-server ./build -a 127.0.0.1 -p 8181 &

Starting up http-server, serving ./build

http-server version: 14.0.0

http-server settings:
CORS: disabled
Cache: 3600 seconds
Connection Timeout: 120 seconds
Directory Listings: visible
AutoIndex: visible
Serve GZIP Files: false
Serve Brotli Files: false
Default File Extension: none

Available on:
  http://127.0.0.1:8181
Hit CTRL-C to stop the server


> test:smoke:build:run
> DEPLOY_TARGET=build run-s test:smoke


> test:smoke
> playwright test --config=test/smoke.config.ts --project=firefox

Using config at [...]/test/smoke.config.ts

Running 1 test using 1 worker

[...]

  1 passed (3s)

To open last HTML report run:

  npx playwright show-report


> test:smoke:build:stopserver

> kill $(lsof -t -i:8181)

http-server stopped.

As you can see, the http-server is started, the playwright tests are run successfully, and eventually the http-server is stopped.

When running with GoCD, the job gets stuck as soon as the http-server has been started:

##|20:25:55.223 [go] Job Started: 2022-01-15 20:25:55 CET
[...]
!!|20:28:19.317 [go] Task: npm run test:smoke:build
&1|20:28:20.563
&1|20:28:20.564 > test:smoke:build
&1|20:28:20.566 > run-s --continue-on-error test:smoke:build:startserver test:smoke:build:run test:smoke:build:stopserver
&1|20:28:20.569
&1|20:28:22.395
&1|20:28:22.396 > test:smoke:build:startserver
&1|20:28:22.397 > http-server ./build -a 127.0.0.1 -p 8181 &
&1|20:28:22.398
&1|20:28:23.608 Starting up http-server, serving ./build
&1|20:28:23.611
&1|20:28:23.612 http-server version: 14.0.0
&1|20:28:23.613
&1|20:28:23.614 http-server settings:
&1|20:28:23.615 CORS: disabled
&1|20:28:23.616 Cache: 3600 seconds
&1|20:28:23.616 Connection Timeout: 120 seconds
&1|20:28:23.617 Directory Listings: visible
&1|20:28:23.618 AutoIndex: visible
&1|20:28:23.619 Serve GZIP Files: false
&1|20:28:23.620 Serve Brotli Files: false
&1|20:28:23.622 Default File Extension: none
&1|20:28:23.623
&1|20:28:23.624 Available on:
&1|20:28:23.625   http://127.0.0.1:8181
&1|20:28:23.626 Hit CTRL-C to stop the server
&1|20:28:23.627
!x|20:35:11.221 [go] On Cancel Task: Kills child processes
##|20:35:11.221 [go] Attempting to kill child processes.
x0|20:35:11.346 [go] On Cancel Task completed
^C|20:35:11.593 [go] Task status: failed (412276 ms) (exit code: 143)
ex|20:35:11.666 [go] Job completed [...]/15/Build/1/Build-Site on [...] [/var/lib/go-agent]

GoCD warns about the possibility that the job may be hung:

Screen Shot 2022-01-15 at 20.34.11.png

It is hung indeed. So, I cancelled it manually as you can see in above raw output where I marked it in red text color.

Best wishes,

Martin

Chad Wilson

unread,
Jan 16, 2022, 12:37:08 AM1/16/22
to go...@googlegroups.com
Hi Martin

I get rather confused as to how npm does its thing when interaction with shells, but it's most likely because when you launch something via an automated process such as GoCD you don't have any shell (or the right type, interactive with tty etc) when you launch a process with `npm` as the originating point, so my guess is that the & is being ignored, or not working as you might expect due to lack of interactive shell/stdin.

You could try with a wrapping shell, e.g
Command: bash
Arg[1]: -c
Arg[2] npm run test:smoke:build

Don't have the time to test via npm and npm scripts, but it works fine with raw commands and npx:

image.png
image.png

If none of that works, you might be better to look for something that can be daemonized more easily, or plays nicely with some other process manager like pm2/supervisor etc rather than relying on shell jobs. In my experience often these simpler local dev tools on NodeJS aren't all particularly well suited for automation, but YMMV.

-Chad

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.

Martin Burger

unread,
Jan 16, 2022, 7:50:03 AM1/16/22
to go-cd
Chad, thank you very much for your quick and competent help. Switching to PM2 did the trick within minutes. Best wishes, Martin

Chad Wilson

unread,
Jan 16, 2022, 9:10:26 AM1/16/22
to go...@googlegroups.com
No problem Martin - appreciate the confirmation!

On Sun, Jan 16, 2022 at 8:50 PM Martin Burger <mburg...@gmail.com> wrote:
Chad, thank you very much for your quick and competent help. Switching to PM2 did the trick within minutes. Best wishes, Martin

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages