Is there an easy way to view Gitlab-CI artifacts?

Question

We're migrating our CI from Phabricator/Jenkins to Gitlab and the UX for viewing docs is really not very good. The current workflow from the Merge Request page is

Click build icon > click stage (e.g. build docs) > click Browse button under Job artifacts > click docs directory > click _build directory > click html directory > click index.html link

Seven clicks in all. With Phabricator, the Jenkins bot used to comment in the MR with a link to the docs page, so you could view the docs with a single click. Is there a way to do this with Gitlab?

(I would also like to do the same for coverage and lint reports, but will ask those questions separately, unless anyone has an easy solution that could be applied to all three types of artifact.)

Unbeknown

I am also looking for same. Its a lot of clicks. – Noteworthy

Someone has requested the same thing for coverage reports, but... tumbleweed. gitlab.com/gitlab-org/gitlab/-/issues/217998 – Unbeknown

At one workplace, I wrote a script that the pipeline would run, that used an access token (provided through the environment) to call Gitlab's APIs to create a comment. So I don't have the code, but I just wanted to say that it is possible. Also, set up some filters in your e-mail client if you don't want to be spammed by these (if triggered by every push). – Chirrup

Answer 1

You can use artifacts:expose_as, which links the created artifacts in a section below the most recent pipeline status on the MR overview page.

Example job:

job:
  image: alpine:latest
  script:
    - echo foo > bar.txt
  artifacts:
    expose_as: 'Job Report'
    paths: 
      - 'bar.txt'

Common coverage and lint reports can be included with artifacts:reports.

Another option is to make use of the predictable URL pattern, as described by @KamilCuk, with environment:url. Here is an example to expose storybook:

storybook:
  extends: .storybook_build
  environment:
    name: storybook-$CI_COMMIT_REF_SLUG
    url: 'https://<org>.gitlab.io/-/<path>/<project>/-/jobs/$CI_JOB_ID/artifacts/storybook/index.html'
  artifacts:
    paths:
      - 'storybook/'
    expire_in: 4 weeks
  allow_failure: true

This is just one click away from the MR page.

Donor

Thanks, we're already using expose_as. It doesn't help. How many clicks is it to get from the MR to the coverage report? – Unbeknown

Some information is directly part of the MR overview and the full report is one click away, the caveat is that it is gitlab's own presentation and not just any custom report. – Donor

Ok, we've got a couple of subfolders in our paths list, so that's 2 clicks, but even if index.html was on the first page after you click on the artifacts, there are still two more clicks because "you are being redirected away from Gitlab". – Unbeknown

Yeah it is all not the best experience. We actually now made it work for with an environment url link, added an example from a storybook job to my answer. – Donor

Answer 2

From https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#access-the-latest-job-artifacts-by-url :

To browse the latest job artifacts:

https://example.com/<namespace>/<project>/-/jobs/artifacts/<ref>/browse?job=<job_name>

For example:

https://gitlab.com/gitlab-org/gitlab/-/jobs/artifacts/main/browse?job=coverage

For example:

https://gitlab.com/<namespace>/<yourrepo>/-/jobs/artifacts/master/file/docs/_build/html/index.html?job=build_docs

Radiotransparent

This does not answer my question. While the explanation of the different parts of the URL is useful, it does not show how to reach it with one click from a merge request page. – Unbeknown

Answer 3

This has been added: https://docs.gitlab.com/ee/ci/jobs/job_artifacts.html#view-all-job-artifacts-in-a-project

You can view all artifacts stored in a project from the CI/CD > Artifacts page. This list displays all jobs and their associated artifacts.

It is currently behind a feature flag (artifacts_management_page) and will be enabled be default in version 16.

Alternant

This does make it easier to find artifacts for a project, but it's harder to see them when you are looking at an individual merge request. I tried it and it's 8 clicks, so is actually worse than the existing UI. – Unbeknown