#!/bin/bash -eo pipefail
npm start
npm info it worked if it ends with ok
npm info using npm@5.3.0
npm info using node@v8.2.1
npm info lifecycle medivac@0.2.0~prestart: medivac@0.2.0
npm info lifecycle medivac@0.2.0~start: medivac@0.2.0
> medivac@0.2.0 start /home/circleci/project
> browserify -t babelify lib/public/main.js -o public/assets/scripts/main.js && node lib/server.js
Step was canceled
#!/bin/bash -eo pipefail
npm test
npm info it worked if it ends with ok
npm info using npm@5.3.0
npm info using node@v8.2.1
npm info lifecycle medivac@0.2.0~pretest: medivac@0.2.0
npm info lifecycle medivac@0.2.0~test: medivac@0.2.0
> medivac@0.2.0 test /home/circleci/project
> lab test --leaks
(node:1702) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
/home/circleci/project/lib/server.js:53
if (error) { throw error; }
^
Error: listen EACCES 0.0.0.0:80
How can I start up the server and run tests against it in CircleCI v2?
If you search for that phrase in this forum, it’s been mentioned before. From what I recall, it is just poorly worded - the service does actually start up. If it does not, the problem is likely not to be CircleCI - check the logs of the thing you want to start to see why it failed.
The server starts up fine in my local environment but doesn’t start/stay up here. I suspect the issue is related to running this inside of a container. I’ll try running other servers to see if I can anything running but I don’t know how far I’ll get until I understand how circleci interacts with the container.
Maybe, but usually it’s just misconfiguration - servers mostly don’t know/care they’re in a container. I suggest you get a SSH session on failed build and try to start this server manually, and then see what it says in the logs/console.
- run:
name: Running Autodeploy
command: |
if [ "${CIRCLE_BRANCH}" == "qa" ] || [ "${CIRCLE_BRANCH}" == "development" ]; then
echo "Starting Deployment on ${CIRCLE_BRANCH}"
ssh -v root@ip "cd scripts/${CIRCLE_BRANCH} && ./${CIRCLE_BRANCH}-1.sh && exit"
else
echo "Auto deploy is not enabled in ${CIRCLE_BRANCH}. Only in qa and development"
fi
background: true
The script has been tested from server to server and from local to server and works as expected, with no errors.
Output from CircleCI workflow summary
#!/bin/bash -eo pipefail
if [ "${CIRCLE_BRANCH}" == "qa" ] || [ "${CIRCLE_BRANCH}" == "development" ]; then
echo "Starting Deployment on ${CIRCLE_BRANCH}"
ssh -v root@ip "cd scripts/${CIRCLE_BRANCH} && ./${CIRCLE_BRANCH}-1.sh && exit"
else
echo "Auto deploy is not enabled in ${CIRCLE_BRANCH}. Only in qa and development"
fi
Step was canceled
Successful output from local to server:
debug1: Sending command: cd scripts/development && ./development-1.sh && exit
Login Succeeded
Pulling development ... done
development-1
development-1
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2804, received 3080 bytes, in 27.9 seconds
Bytes per second: sent 100.7, received 110.6
debug1: Exit status 0
@lcampanis: I am not sure it is clear what you are asking.
From a helper perspective, if I see “we have the same issue” or “see above” then I have to grok another problem in order to understand the current one. That may cause readers to believe a question will be a hard slog, and they may move on. This forum, in addition, does not have many active helpers.
It looks like you are saying that your ssh -v root@ip block produces no errors. Why is it being backgrounded? Can this be tried without the background switch temporarily? If you do have a good reason to background it, have you tried the & flag instead?
Moreover, your last log output appears to show that your deployment script was successful, which is mighty confusing - what problem are you experiencing?
I don’t know if this solves your issue, but in case it helps others…
I was having intermittent problems that I was blaming on “Step was cancelled” messages. It turns out that’s a product of timing…
My behat test would fail because it couldn’t find anything serving on the correct port, so when I looked back at the step to start the local server, I saw “Step was cancelled”. But that’s because the build was already over, and once a build ends all background processes are stopped. In reality behat was failing because the step to run it started before my background process was ready to receive requests.
My solution was to use Dockerize to wait for the server to be ready before moving on the the next step.
This might not be the solution you need, but it may be for others brought here by Google, as I was. Props to @FelicianoTech for helping me get my solution.