This is caused by a combination of copying the files into the image generated by building the
Dockerfile, and then mounting the cloned repository when actually running your steps.
Dockerfile you switch
package.json and run
yarn (which implies the
install subcommand). If you also specify
cached: true via your
codeship-services.yml file, the generated Docker image is cached by Codeship, which would explain the fast build times. If you also uncomment the
RUN yarn blendid build step, the built artifacts would also be added to the Docker image and would be available during your build.
However, since you also specify a volume via your services file, that is mounted at the same
/app path and mounted volumes take precedence over any files persisted via the Docker image, both the
yarn [install] and currently commented out
yarn blendid build steps are not taking effect.
Basically the contents of
/app as modified by the commands in your
Dockerfile are replaced by the pristine state as contained in your cloned repository.
To solve this, either rely on the volume to share those changes with future steps (and then run both
yarn commands via the
codeship-steps.yml file), or rely on the
Dockerfile to run those commands, and then have a step copy the contents you want to deploy to a (separate) directory that is mounted as a volume.
For an example of the latter, take a look out our documentation repository. We rely on the
Dockerfile to install required dependencies and work out of the
/docs directory. For deployment we then copy the (in this case mostly HTML files) to the
/site directory, which is mounted via a volume and shared with the actual deployment container.