Gitlabs artifact of one project used in further projects

rafa.ferreira picture rafa.ferreira · Sep 13, 2016 · Viewed 8k times · Source

Question

  • What is the best way to carry artifacts (jar, class, war) among projects when using docker containers in CI phase.

Let me explain my issue in details, please don't stop the reading... =)

Gitlabs project1

  • unit tests
  • etc...
  • package

Gitlabs project2

  • unit test
  • etc...
  • build (failing)
    • here I need one artifact (jar) generated in project1

Current scenario / comments

  • I'm using dockers so in each .gitlab-ci.yml I'll have independent containers
  • All is working fine in project1
  • If I use "shell" instead of dockers in my .gitlab-ci.yml I can keep the jar file from the project1 in the disk and use when project2 kicks the build
  • Today my trigger on call project2 when project1 finish is working nicely
  • My artifact is not an RPM so I'll not add into my repo

Possible solutions

Answer

Sebastian Höffner picture Sebastian Höffner · May 9, 2019

In GitLab silver and premium, there is the $CI_JOB_TOKEN available, which allows the following .gitlab-ci.yaml snippet:

build_submodule:
  image: debian
  stage: test
  script:
  - apt update && apt install -y unzip
  - curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/master/download?job=test&job_token=$CI_JOB_TOKEN"
  - unzip artifacts.zip
  only:
  - tags

However, if you do not have silver or higher gitlab subscriptions, but rely on free tiers, it is also possible to use the API and pipeline triggers.

Let's assume we have project A building app.jar which is needed by project B.

First, you will need an API Token. Go to Profile settings/Access Tokens page to create one, then store it as a variable in project B. In my example it's GITLAB_API_TOKEN.

In the CI / CD settings of project B add a new trigger, for example "Project A built". This will give you a token which you can copy. Open project A's .gitlab-ci.yaml and copy the trigger_build: section from project B's CI / CD settings trigger section.

Project A:

trigger_build:
  stage: deploy
  script:
    - "curl -X POST -F token=TOKEN -F ref=REF_NAME https://gitlab.example.com/api/v4/projects/${PROJECT_B_ID}/trigger/pipeline"

Replace TOKEN with that token (better, store it as a variable in project A -- then you will need to make it token=${TRIGGER_TOKEN_PROJECT_B} or something), and replace REF_NAME with your branch (e.g. master).

Then, in project B, we can write a section which only builds on triggers and retrieves the artifacts.

Project B:

download:
  stage: deploy
  only:
    - triggers
  script:
    - "curl -O --header 'PRIVATE-TOKEN: ${GITLAB_API_TOKEN}' https://gitlab.example.com/api/v4/projects/${PROJECT_A_ID}/jobs/${REMOTE_JOB_ID}/artifacts/${REMOTE_FILENAME}"

If you know the artifact path, then you can replace ${REMOTE_FILENAME} with it, for example build/app.jar. The project ID can be found in the CI / CD settings.

I extended the script in project A to pass the remaining information as documented in the trigger settings section:

Add variables[VARIABLE]=VALUE to an API request. Variable values can be used to distinguish between triggered pipelines and normal pipelines.

So the trigger passes the REMOTE_JOB_ID and the REMOTE_FILENAME, but of course you can modify this as you need it:

curl -X POST \
     -F token=TOKEN \
     -F ref=REF_NAME \
     -F "variables[REMOTE_FILENAME]=build/app.jar" \
     -F "variables[REMOTE_JOB_ID]=${CI_JOB_ID}" \
     https://gitlab.example.com/api/v4/projects/${PROJECT_B_ID}/trigger/pipeline