Step was cancelled


I’m trying to test a NodeJS application before I build it to a Docker image. The tests run fine locally. Here’s the test config:

version: 2
      - image: circleci/node:8.2.1
      - checkout
      - run:
          name: Check node
          command: node -v
      - run:
          name: Install dependencies
          command: npm install && npm rebuild node-sass && mkdir -p public/assets/scripts
      - run:
          name: Start server
          command: npm start
          background: true
      - run:
          name: Run tests
          command: npm test

This is the output from the build log:

#!/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.
  if (error) { throw error; }

Error: listen EACCES

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.


I was able to get the server started by starting it on port 8080. Maybe I need to specify the user as root to open up privileged ports.


That sounds exactly like the issue. It would be great if you could report back if that’s the case.


We have the same issue.

The config is as follows:

- 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} && exit"
        echo "Auto deploy is not enabled in ${CIRCLE_BRANCH}. Only in qa and development"
    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} && exit"
  echo "Auto deploy is not enabled in ${CIRCLE_BRANCH}. Only in qa and development"
Step was canceled

Successful output from local to server:

debug1: Sending command: cd scripts/development && ./ && exit
Login Succeeded
Pulling development ... done
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype 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

Any advice from the CircleCI team would be great.

Thank you.


@FelicianoTech Could you please provide some light into this please? Thank you!


@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.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.