First of all, please get rid of that first step. That’s a terrible series of commands to run, especially by default. There is literally no good reason to flush the Docker cache unless you’re running low on disk space and ultimately, this will make not just this build, but any builds that rely on Docker take substantially longer than they should.
Second, why are you running the containers as separate instances instead of using docker compose and the compose YAML file?
Third, you’re running the frontend in foreground mode… since there are no requests coming in, there’s eventually no output and Bamboo kills the build since it appears to have hung.
This did not work. Responded with compose not a docker command maybe docker-compose up -d might work. I have just got that idea now
kindly drop me more explanation of what u mean by saying running the frontend in foreground mode
Checking the logs, seams i have deleted all docker cache and reset docker to default. I thought every build is assigned a different runner just like with GitHub actions.
It should… IIRC, we don’t have the compose extension installed, but the older version using docker-compose should work.
Most of your docker commands had the -d flag as part of the run command which instructs Docker to run the container as a background (daemon) process. The command to run the frontend, however, did not have this flag, so it is run as a foreground process. Basically, if you ran the same command locally, if you ran it with-d, the container would start and then you would get your prompt back whereas if you didn’t run it with -d (necessary for any interactive process) your terminal window would be taken over by the docker container.
Even if that were the case, it still wouldn’t be the right thing to do. But, no, we only have 3 runners.
Did you take a look at how any of our current projects that use Node and NPM work?
A few things that stand-out:
There are no active agents that report supporting any version of NPM or NodeJS, so setting up a job that depends on those is bound to fail.
You have a step that runs a shell script that cds into a directory and then does nothing else… This is not going to have the effect you think it will have because the agent won’t track the changed working directory across scripts… Scripts are run in a shell that’s started from the same CWD every time (this is pretty universally true of every CI system I’ve worked with).
The short version is that we have (for better or worse) nvm installed on the agents, so to run an NPM script, you should actually setup a Shell script which runs nvm, selecting whatever version of Node and NPM is appropriate (similar to GitHub Actions setup-node step) and then just run npm run ... where ... is whatever command you need to run, e.g.
The ideal way to make the test output more understandable would be to configure the test runners to output test results in the JUnit format, at least when run from Bamboo and then tell the Bamboo job where it should look for those test results…
