Блог

Я хочу создать образ сингулярности в GitLab CI. К сожалению, официальные контейнеры терпят неудачу с:

 Running with gitlab-runner 13.5.0 (ece86343) on gitlab-ci d6913e69
Preparing the "docker" executor
Using Docker executor with image quay.io/singularity/singularity:v3.7.0 ...
Pulling docker image quay.io/singularity/singularity:v3.7.0 ...
Using docker image sha256:46d3827bfb2f5088e2960dd7103986adf90f2e5b4cbea9eeb0b0eacfe10e3420 for quay.io/singularity/singularity:v3.7.0 with digest quay.io/singularity/singularity@sha256:def886335e36f47854c121be0ce0c70b2ff06d9381fe8b3d1894fee689615624 ...
Preparing environment
Running on runner-d6913e69-project-2906-concurrent-0 via <gitlab.url>...
Getting source from Git repository
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in <repo-path>
Checking out 708cc829 as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
Error: unknown command "sh" for "singularity"
 

сразу же в начале, при использовании такого задания, как это:

 build-singularity:
  image: quay.io/singularity/singularity:v3.7.0
  stage: singularity
  script:
    - build reproduction/pipeline/semrepro-singularity/semrepro-singularity.sif reproduction/pipeline/semrepro-singularity/semrepro-singularity.def
  only:
    changes:
      - reproduction/pipeline/semrepro-singularity/semrepro-singularity.def
      - reproduction/pipeline/semrepro-singularity/assets/mirrorlist
      - .gitlab/ci/build-semrepo-singularity.yml
  artifacts:
    paths:
      - reproduction/pipeline/semrepro-singularity/semrepro-singularity.sif
    expire_in: 1 hour
  interruptible: true
 

Мне кажется, что GitLab пытается использовать оболочку, которой не существует? Как они должны работать? В официальном примере они используют специальную версию вызываемого образа docker -gitlab , но, к сожалению, она больше не доступна. Есть какие-нибудь идеи? Я не могу себе представить, что невозможно создать контейнеры сингулярности в CI? Заранее большое спасибо!

РЕДАКТИРОВАТЬ: Согласно ответу @tsnowlan, переопределение точки входа устраняет вышеуказанную проблему. Однако теперь сборка завершается неудачно с:

 singularity build semrepro-singularity.sif semrepro-singularity.def
INFO:    Starting build...
INFO:    Downloading library image
84.1MiB / 84.1MiB [========================================] 100 % 28.7 MiB/s 0s
ERROR:   unpackSIF failed: root filesystem extraction failed: extract command failed: ERROR  : Failed to create user namespace: not allowed to create user namespace: exit status 1
FATAL:   While performing build: packer failed to pack: root filesystem extraction failed: extract command failed: ERROR  : Failed to create user namespace: not allowed to create user namespace: exit status 1
Cleaning up file based variables
ERROR: Job failed: exit code 1
 

Есть идеи?

Вам нужно немного доработать его, чтобы он хорошо работал с gitlab CI. Самый простой способ, который я нашел, — это заблокировать точку входа docker и сделать так, чтобы этап сценария был полной командой сборки singularity. Мы используем это для создания наших изображений singularity с версией v3.6.4, но оно должно работать и с версией v3.7.0.

например,

 build-singularity:
  image: 
    name: quay.io/singularity/singularity:v3.7.0
    entrypoint: [""]
  stage: singularity
  script:
    - singularity build reproduction/pipeline/semrepro-singularity/semrepro-singularity.sif reproduction/pipeline/semrepro-singularity/semrepro-singularity.def
  ...
 

редактировать: используемый gitlab-runner также должен privileged быть включен. Это значение по умолчанию для gitlab.com общие бегуны, но если вы используете свои собственные бегуны, вам нужно убедиться, что это задано в их конфигурации.