Using gitlab-ci to cache maven repository 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.
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.