4

we have a gitlab runner running in a kubernetes cluster on AWS. the testjob:

test-job:
  image: centos
  stage: build
  cache:
    paths:
     - output
  script:
    - mkdir -p output
    - date +"%Y-%m-%d" > output/date.txt
  tags:
    - docker
  when: always
takes about 4 minutes to run - but only 4s if i remove the "cache" section.

my runner's config.toml looks like this

[[runners]]
  name = "gitlab-runner..."
  url = "https://gitlab...."
  token = "....."
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    Type = "s3"
    Shared = true
    [runners.cache.s3]
      AccessKey = "...."
      SecretKey = "...."
      BucketName = "runner-cache-bucket-name"
      BucketLocation = "eu-central-1"
  [runners.docker]
    tls_verify = false
    image = "ruby:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/var/run/docker.sock:/var/run/docker.sock"]
    shm_size = 0

i also tried using an instance profile (same config but without access/secret key).

this configuration works ... it just hangs a long time before and after the "scripts" part. the config seems to be pretty straightforward.

here is the runner log:

Running with gitlab-runner 14.5.2
  on gitlab-runner-....
Preparing the "docker" executor                                                 00:02
Using Docker executor with image centos ...
Pulling docker image centos ...
Using docker image .....
Preparing environment                                                           00:00
Running on runner-.... 
Getting source from Git repository                                              00:01
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/test/.git/
Checking out db156a5f as master...
Removing output/
Skipping Git submodules setup

# [ here, it hangs for 2 minutes ] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Restoring cache                                                                 00:01
Checking cache for default...
Downloading cache.zip from https://.......s3.dualstack.eu-central-1.amazonaws.com/project/69/default 
Successfully extracted cache
Executing "step_script" stage of the job script 00:01
Using docker image ....
$ mkdir -p output
$ date +"%Y-%m-%d" > output/date.txt

# [ here, it hangs again for 2 minutes ] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Saving cache for successful job                                                 00:01
Creating cache default...
output: found 2 matching files and directories     
Uploading cache.zip to https://.........s3.dualstack.eu-central-1.amazonaws.com/project/69/default 
Created cache
Cleaning up project directory and file based variables                          00:00
Job succeeded

note that the times on the right add up to more or less 4s - the time it takes with caching disabled.

EDIT ===================================

I added this to the configuration:

ServerAddress = "s3.amazonaws.com"

Now it works as expected. So, my question would be: why does it work - albeit slowly - without that configuration?

sytech
  • 29,298
  • 3
  • 45
  • 86
rmalchow
  • 2,689
  • 18
  • 31

1 Answers1

0

use these variables for faster zip:

variables:
  FF_USE_FASTZIP: "true" # enable fastzip - a faster zip implementation that also supports level configuration.
  ARTIFACT_COMPRESSION_LEVEL: default # can also be set to fastest, fast, slow and slowest. If just enabling fastzip is not enough try setting this to fastest or fast.
  CACHE_COMPRESSION_LEVEL: default # same as above, but for caches
  TRANSFER_METER_FREQUENCY: 5s # will display transfer progress every 5 seconds for artifacts and remote caches.

reference: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1797

marstone
  • 686
  • 1
  • 10
  • 23