› ~/

Usage Quotas, job artifacts and GitLab Pages

2022-01-07 #GitLab #Hugo

I recently set-up a static homepage that is hosted on GitLab pages, which contains quite a few large images which tallys up to around 170MB and around 30MB when compressed.

When a GitLab pipeline is being executed, the artifacts that are produced in each job will be stored and the default expiration time of an artifact is 30 days. GitLab offers a generous usage quota of 10GB per project, which consits of

If you exceed this quota, you can’t push changes to the repository because it has been locked.

If you would make a lot of changes to this static site within a one month window, you might be able to be locked out since it is quite large. I know its a better idea to have the images on a CDN but they are in the repo for now. The size of the repository also shines some light on the issue, since a text only repo would have a hard time reaching the storage quota.

The expiration time of a job artifact can be configured with artifacts:expire_in in .gitlab-ci.yml.

The documentation for expire_in contains a key bit of information, namely:

Use expire_in to specify how long job artifacts are stored before they expire and are deleted. The expire_in setting does not affect:

Artifacts from the latest job, unless keeping the latest job artifacts is:

Disabled at the project level. Disabled instance-wide.

Which means that you can safely expire artifcts fairly quickly to not run into the storage quota limit, because the last artifact will be kept. I’m not sure if GitLab uses an additional layer of storage for pages, which is de-coupled from artifacts but it seems to work.

This is a simplified version of the deploy script, which will purge the artifacts within 2 min instead of 30 days.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

image: registry.gitlab.com/pages/hugo/hugo_extended:latest

pages:
  script:
  - hugo
  artifacts:
    expire_in: '2 min'
    paths:
    - public
  only:
  - master

The resolved issue for this behaviour can be found here

The reason I’m aware of this is because of this open issue, which contains a lot of good information and actual tests of the behaviour for pages.

I guess storage is cheap so it doesn’t really matter for GitLab that there are a bunch of unnecessary artifacts lying around but it seems strange that this is not mentioned in the pages documentation or in the example repositories for pages.

Written by
Andreas