Feedback

Chat Icon

Cloud Native CI/CD with GitLab

From Commit to Production Ready

Managing Artifacts in GitLab CI/CD: Data Sharing Between Jobs
48%

Displaying Artifacts in the Merge Request UI

When you have a merge request, this is what typically happens:

  • Step 1: You are coding on a feature branch.
  • Step 2: You push code to the remote repository on the feature branch.
  • Step 3: A pipeline is triggered automatically on the feature branch (if .gitlab-ci.yml is present).
  • Step 4: You choose to merge the code from the feature branch to the main branch once the code is reviewed and approved.
  • Step 5: When merging, the pipeline is triggered automatically on the main branch (if .gitlab-ci.yml is present).

At step 4, before deciding to merge the code, it could be useful to see some artifacts generated by the pipeline directly in the merge request UI. For example, you may want to see the test coverage report, code quality report, linting report, and so on.

It's also convenient to give a friendly name to each artifact to make it easier to understand its content and purpose.

In GitLab CI/CD, this is done using the expose_as keyword. In the following example, we will create a new branch, add the expose_as keyword to the flake8.txt artifact, and push the changes to the remote repository:

# Create a new branch
git checkout -b feature/testing-artifacts

Change the .gitlab-ci.yml file as follows and add the expose_as keyword:

cat <$HOME/todo/app/.gitlab-ci.yml && \
cd $HOME/todo/app && \
git add . && \
git commit -m "Add expose_as" && \
git push origin feature/testing-artifacts
image: python:3.12

stages:
  - build
  - test
  - report

build:
  stage: build
  script

Cloud Native CI/CD with GitLab

From Commit to Production Ready

Enroll now to unlock all content and receive all future updates for free.