• You might want to change docker pull $CONTAINER_IMAGE:latest to docker pull $CONTAINER_IMAGE:latest ||true in case that image does not exist. Also you should be able to replace registry.anuary.com wich $CI_REGISTRY.

  • I came across this while looking for .gitlab-ci.yml examples.

    Just FYI.

    You are doing docker push $CONTAINER_IMAGE:latest before the test stage. You might want to do that in the release stage, to avoid pushing a broken latest image.

    However, this is tricky, since the dind service is not shared between the different scripts and stages. On https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#using-the-gitlab-container-registry they are building and pushing a test image in the build stage, which is then pulled in the different test stages and finally pulled, renamed and pushed in the deploy stage.

    It would be great if services could be shared between different stages and scripts to be able to avoid this pushing and pulling back and forth, but AFAIK that's not possible so far.

    Edited by Peter Billen
  • @cmorty Apparently composite commands need to be put in parens, i.e. (docker pull $CONTAINER_IMAGE:latest || true)

  • @trkoch: It works well for me. The braces start a sub-shell, which shouldn't be necessary, as every line is run in a separate shell (if I remember things right).

  • I think that's better to use by this way:

        - docker pull $CONTAINER_IMAGE:latest \
          && docker build --cache-from $CONTAINER_IMAGE:latest --build-arg NPM_TOKEN=${NPM_TOKEN} -t $CONTAINER_IMAGE:$CI_BUILD_REF -t $CONTAINER_IMAGE:latest .

    Using this, you guarantee that the result was positive. Captura_de_tela_de_2020-04-24_10-50-33

  • @bemanuel: Nope. That will fail if you delete that image from the registry.... - not only if your configuration is wrong.

    Besides: kaniko is the way to go. DinD is a security hell.

    Edited by Morty
  • @cmorty I tried Kaniko when first setting up my pipeline, it was a complete nightmare, every action requires it to take a filesystem snapshot which end ups consuming ~20min in a single docker build. After that I migrated to d-in-d and now they take ~5min

  • @diestrin: Unfortunately Kaniko still has quite some issues. After multiple successful projects I had to migrate one back. Though for me it wasn't a performance issue, but the resulting image didn't work. Yet that does not make DinD less of a security hell - at least if you have a shared server.

  • @cmorty you can also deploy a pod with docker running on it and use that as your private docker daemon

  • @diesten: Unfortunately that does not integrate well into our CI. :( Gitlab having native support for docker-files would go a long way. :) Or docker being able to open sockets with limited capabilities, or ...

  • @gajus perhaps you meant, "Using Docker --cache-from". 😄

    Edited by Lucas Ramage
  • When with DOCKER_BUILDKIT=1, using --cache-from on gitlab will report this error:

    #8 ERROR: invalid build cache from {MediaType:application/vnd.docker.distribution.manifest.v2+json Digest:sha256:1e015f8fbc156c3a9f5f353bd75da9a3701f2dcc144057c9e82625d11fcca0a3 Size:7221 URLs:[] Annotations:map[] Platform:<nil>}
    rpc error: code = Unknown desc = error on cache query: invalid build cache from {MediaType:application/vnd.docker.distribution.manifest.v2+json Digest:sha256:1e015f8fbc156c3a9f5f353bd75da9a3701f2dcc144057c9e82625d11fcca0a3 Size:7221 URLs:[] Annotations:map[] Platform:<nil>}

    Is there any solutions?

  • @zengqingfu I just discovered you need to use --build-arg BUILDKIT_INLINE_CACHE=1, as detailed here.

    Edit: I think this is actually for layer level caching, but worth knowing. This is a useful article.

    Edited by Toby Griffiths
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment