Strider-CD / strider-docker-runner

Strider runner that uses Docker
34 stars 19 forks source link

The node.js plugin doesn't run npm install with this runner #18

Open jfromaniello opened 9 years ago

jfromaniello commented 9 years ago

If I switch from the simple-runner to the docker-runner, the node.js plugin seems to run the npm install from the node.js plugin.

It works if I npm install from the Custom Scripts plugin

kfatehi commented 9 years ago

@knownasilya this is blocked, see https://github.com/Strider-CD/strider-heroku/issues/4#issuecomment-54719228

oliversalzburg commented 7 years ago

I'm looking into this right now. The problem seems to originate from strider-node: https://github.com/Strider-CD/strider-node/blob/master/worker.js#L35

path.join(projectDir, 'package.json') will resolve to a location on the Docker host, not the guest, so Npm install is not called.

There are really a lot of confusing things going on here. It's not that the paths are incorrectly set, strider-docker-runner will still let strider-simple-runner do a lot of work. Which in turn creates directories on the host (like the data and cache directories). This should be a big no-no when considering that we're trying to run stuff in isolation.

@knownasilya, do you have a deeper understanding how all these components are mixed with each other? Saying this is a huge mess is kind of an understatement. The callback hell is very real with this problem.

oliversalzburg commented 7 years ago

So, digging deeper into the issue. strider-docker-runner makes use of strider-simple-runner, so we will have 2 job queues (strider-simple-runner/lib/jobqueue.js). The job queue is what will invoke our runners, invoke processJob and, thus, cause the incorrect directories in the Docker context.

IMHO, strider-docker-runner must have it's own job queue that is not bound strongly to the processJob method of strider-simple-runner.

oliversalzburg commented 7 years ago

Okay, so the problem isn't that the paths are wrong. The paths are kinda right, except that the whole plugin is not running in the Docker context. So even if the paths are set to /home/strider/workspace, everything still fails, because it's not executed in the container.

oliversalzburg commented 7 years ago

This is really impossible to fix IMHO. The code is such a mess I wouldn't even know where to start. The best that could (and probably should) be done, is a big fat error that tells you that no plugins are compatible with the docker runner.

oliversalzburg commented 7 years ago

Okay, more progress reporting. We're now using an updated docker image: https://github.com/fairmanager/strider-docker-slave

This gives us a newer OS, Node and npm. It also has support for private npm through setting NPM_TOKEN in the environment plugin.

The custom plugin seems mandatory when using Docker. This way you can run npm install in the prepare phase. We've already had a setup for this, so this was easy. IMHO it is best controlled through strider.json:

{
    "runner": {
        "id": "docker"
    },
    "merge_plugins": true,
    "plugins": [
        {
            "id": "custom",
            "enabled": true,
            "showStatus": true,
            "config": {
                "prepare": ".scripts/prepare.sh --<%= ref.branch %>",
                "deploy": ".scripts/deploy.sh --<%= ref.branch %>"
            }
        }
    ]
}

Then you just drop prepare code into .scripts/prepare.sh:

#!/bin/sh
self=`readlink -f "$0"`
basedir=`dirname "$self"`

echo "node -v"; node -v
echo "npm -v"; npm -v

cd ${basedir}
npm install

Now, because we don't run with the Node plugin, no actual testing is done. That's a task for another day :P

knownasilya commented 7 years ago

Glad you could make some head way on this.

oliversalzburg commented 7 years ago

This should work now with HEAD of strider-docker-runner and strider-node, without using strider-custom for npm install. Would love some feedback :)