So I had some time off and came back realizing the migration from 1.0 to 2.0 I’d put off for months couldn’t be put off anymore. Now I’m trying to do the migration and I’m encountering some issues.
When I run this, it runs to an npm install and fails it seems to be installing the dependencies with node 4.6.2 which is weird since the build image is using 8? I’m very confused. Any help would be hugely appreciated
I don’t use NPM, but thought I’d point this out, in case it is the cause of your issue. I see your nvm commands mention 8.* so perhaps I am just not clear on what you are expecting of these two images.
The first of these two images is your build environment, so all your commands are run in a container produced from that image. The second is spun up and becomes a service that you can use over HTTP or TCP - this is often used for key-value stores, databases, web servers, etc. So, I am wondering, is there some Node stuff in the second image you are expecting to be available?
Each time I try to build, it gets through the first bit fine. Then it says:
Cannot find a job named deploy to run in the jobs: section of your configuration file.
If you expected a workflow to run, check your config contains a top-level key called ‘workflows:’
I feel like I’m missing something very obvious here.
Yep - you have run into The Curse Of Yaml, which is an indentation problem. Copy your YAML into this parser to see the issue. Your two jobs build and deploy are keys that should be at the same level, but deploy has become a sub-key of the build object.
Un-indent the deploy section, double-check it with the parser, then commit and push - that should sort it out.
You’re 100% right. It was the indent, it was making it believe it wasn’t there. I just got a valid build a couple of minutes ago and was about to update
Incidentally, Mongo is something that can become a secondary container, in the place you had circleci/node:chakracore-8 previously. You can use any CircleCI convenience image, anything from Docker Hub, or anything from your private registry. As you’d expect, smaller = quicker here, so images based on Alpine (etc) are ideal.
When a secondary container is spun up, the networking stack is merged with the primary container and becomes available on localhost.
However, if your current Mongo install works, I’d suggest not changing it until you’ve got a 2.0 config stable.