6

We have a server running gitlab and gitlab-runners on same machine. I've defined a runner as below

[abc@xyz bin]# gitlab-ci-multi-runner register
Running in system-mode.                            

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://abc.xyz.com                                                                     
Please enter the gitlab-ci token for this runner:
9nev5wz3voabcdefgh
Please enter the gitlab-ci description for this runner:
[opera.ishisystems.com]: second-docker-remote-runner
Please enter the gitlab-ci tags for this runner (comma separated):
docker, remote
Whether to run untagged builds [true/false]:
[false]: 
Whether to lock Runner to current project [true/false]:
[false]: 
Registering runner... succeeded                     runner=9nev5wz3
Please enter the executor: docker, docker-ssh, ssh, docker+machine, docker-ssh+machine, parallels, shell, virtualbox, kubernetes:
docker
Please enter the default Docker image (e.g. ruby:2.1):
node:4.2.2
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 

and my .gitlab-ci.yml is

image: maven:3-jdk-7

services:
  - wurstmeister/kafka:0.8.2.1

variables:
  MAVEN_REPO: "$CI_PROJECT_DIR/.m2"

cache:
    key: "$CI_BUILD_STAGE"
    paths:
      - .m2

build:
  script: "mvn -Dmaven.repo.local=$MAVEN_REPO test -B"
  tags:
  - docker

What I'm trying to do is setup a central maven repository on my gitlab-runner server so that every time a new job is fired instead of downloading all the maven dependencies it should use the cached repository.

7

To me the easiest route to this would be to have an instance of an artifactory running. There are several choices out there many of which have an open-source, community or free version that would support maven repositories. Most options will support caching remote repositories (maven central for example) which can then be curated to enforce specific versions of the dependencies through your projects. It will also accept your own dependencies this way you can have a central unique access point for all maven dependencies in your team.

I've personally had success with Sonatype's Nexus (OSS version, or Pro version). There are other choices out there though check them out.

That said, if what you want is to prime the local repository for a new agent you want to provision, you could do so. But frankly, unless you have some real hefty dependencies (say in the GB size range), I would not bother doing so really and just let Maven naturally pull from the local binary repository instead. It makes for a simpler solution that will be more robust in the long run.

  • What I wanted was to use gitlab-ci's cache feature. Can you help me out with that. – radbrawler Apr 26 '17 at 17:29
  • though what I wanted was different but you've put a good option for me and my team to discuss upon. Thanks @Newtopian – radbrawler Apr 26 '17 at 17:30
  • I don't have big experience with gitlab-ci so I cant really help there. However when trying something similar with Team-City (artifacts in their lingo) we did end up with issues that the artifactory just naturally solved. The killer sell point was that it enabled a whole lot of new options that we did not even consider before further simplifying the overall pipeline. It just felt right as a whole swath of relative awkwardness found a natural home to settle in. – Newtopian Apr 26 '17 at 18:04
  • Sorry for the nitpicking ... and hijacking your answer to soon post a new question (hang on ...). – Pierre.Vriens Aug 31 '17 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.