How to speed up GitLab runner?

I have a GitLab runner via Docker on a t2.medium AWS instance (disk is gp3) for the following .gitlab-ci.yml:

# This file is a template, and might need editing before it works on your project.
# To contribute improvements to CI/CD templates, please follow the Development guide at:
# https://docs.gitlab.com/ee/development/cicd/templates.html
# This specific template is located at:
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml

# Official language image. Look for the different tagged releases at:
# https://hub.docker.com/r/library/python/tags/
image: python:3.10

# Change pip's cache directory to be inside the project directory since we can
# only cache local items.
variables:
    PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"

# Pip's cache doesn't store the python packages
# https://pip.pypa.io/en/stable/topics/caching/
#
# If you want to also cache the installed packages, you have to install
# them in a virtualenv and cache it as well.
cache:
    paths:
        - .cache/pip
        - venv/

before_script:
    - python --version ; pip --version # For debugging
    - pip install virtualenv
    - virtualenv venv
    - source venv/bin/activate

stages:
    - build
    - lint

build:
    stage: build
    script:
        - pip install -r requirements-dev.txt

lint:
    stage: lint
    script:
        - flake8 .
        - mypy src

formatting:
    stage: lint
    script:
        - black --check .
        - isort --check .

I have the following problems:

• it works super slow (for example, build stage takes 8 minutes), especially caching
• for some unknown reasons, cache creation occurs after every job. I do not really understand why, as linting and formatting jobs do not change anything inside venv directory.
• after several runs cache creation fails as disk becomes full (it only 16 GB). How to teach GitLab runner to clean the disk?

There is some things you could try to speed up what you are doing.

Firstly, you could create a docker image that contains your python requirements in it, then use that as the docker image for your job (gitlab allow you to specify custom docker images to run on).

I’m not 100% on the caching issue I’m afraid. But maybe the above can help if the requirements are pre installed. The only caveat is that if you change these or update them, you’d need an updated image to reflect the change which is maybe too much overhead.

And on the last part with the issue on disk space. Just like you have a before_script job, you can have an after_script job. You could use this to remove any files that aren’t required and save on disk space by deleting things that are either older than a certain date perhaps?