LINUX.ORG.RU

GitHub Actions разделение checkout и сборки

 


0

2

Разбираюсь с GitHub Actions. Хочется запустить сборку кода в моем контейнере, при этом никак не модифицировать образ. В GitLab CI можно было сделать так:

build:
  image: my-image
  script:
    - build-my-project.sh

При этом GitLab Runner сам клонирует код и подмонтирует его в мой контейнер, запущенный на основе образа my-image.

В GitHub Actions типовая сборка выглядит следующим образом:

name: CI
on:
  push:
    branches: [ main ]
jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container: my-image
    steps:
      - name: Check out repository code
        uses: actions/checkout@v5
      - run: ./build-my-project.sh

При этом actions/checkout@v5 - это скрипт на Node.JS, т.е. чтобы у меня сработал checkout в контейнере должен быть установлен этот самый Node.JS. Таким образом, чтобы запустить сборку мне нужно подготовить образ, который содержит не только инструменты для сборки, но и инструменты для работы GitHub Actions. Теоретически для служебных задач кроме Node.JS может потребоваться что-то еще, поэтому процесс подготовки образа - нетривиальная задача.

Можно ли сделать так, чтобы шаг checkout выполнился в каком-то контейнере, который содержит инструменты для выполнения GitHub Actions, а шаг сборки - выполнился бы в контейнере для сборки, который содержит только инструменты для сборки, без Node.JS?

Перемещено hobbit из general

Ответ на: комментарий от LamerOk

Не понимаю: почему разделение служебного действия (checkout) и сборки - непонятные извращения?

Посмотрел исходники actions/checkout - это просто нодовскаая обертка, которая выполняет git. То есть фактически можно доставить в образ только git и дернуть его руками.

Goganchic ★★
() автор топика

который содержит только инструменты для сборки, без Node.JS

А какой в этом сакральный смысл? Этот контейнер чисто технический, он никуда не попадает. В нём запускается докер и там уже происходит сборка как тебе надо.

no-such-file ★★★★★
()
Ответ на: комментарий от Goganchic

Не понимаю: почему разделение служебного действия (checkout) и сборки - непонятные извращения?

Потому что люди не понимают сакральный (?) смысл этого извращения, очевидно же.

LamerOk ★★★★★
()
...
    steps:
      - name: Dependencies
        uses: daaku/gh-action-apt-install@v4
        with:
          packages: пакеты через пробел

      - name: Check out repository code
        uses: actions/checkout@v5

      - name: bash
        run: bash ./build-my-project.sh
...
ext4
()
Ответ на: комментарий от Goganchic

Что если для сборки моего проекта нужен какой-то особенный дистрибутив?

делаешь dockerfile для своих особенных дистрибутивов и запускаешь их в gitlab ci/cd ubuntu-latest.

anonymous2 ★★★★★
()
Последнее исправление: anonymous2 (всего исправлений: 1)
Ответ на: комментарий от anonymous2

Насколько я понял ему не нравится то что в github собирают контейнер докером который не умеет сам собирать контейнеры а может только клонировать.

И приводит в пример gitlab который собирает контейнер с 0 сам, на основании (я думаю) того же buildah к примеру.

mx__ ★★★★★
()

Я так понимаю, ты хочешь использовать self hosted github worker.

Он вообще говоря никаких контейнеров не использует и не поддерживает. Это обычный процесс в твоей ОС. Если ты хочешь запускать его в контейнере, тебе надо это всё как-то самому сделать: собрать образ и запускать его. Проблем с этим вероятно не будет, но ты будешь это делать сам. А action это обычная программка на каком-то языке, которую worker скачивает и запускает.

На всякий случай упомяну, что все эти actions использовать не обязательно. Я, например, не использую. У меня десятки проектов, все собираются через docker build . и для всех настроен один workflow, можешь посмотреть тут, он, к сожалению, в силу специфики Github CI должен лежать в публичном репозитории. node на моём build server не установлен, и вообще почти ничего не установлено кроме docker и git.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 5)

У меня была задача собирать код в окружении которое имеет слишком старый libc и в нём не реботал checkout action.

Решилось следующим образом:

  • делаем docker-образ с окружением для сборки, запихиваем его непример в ghcr.io
  • используем достатончо необычный синтаксис uses который использует альтернативный docker-контейнер для запуска определённого скрипта из только что сделанного checkout:
      - uses: docker://ghcr.io/user/image:label
        with:
          entrypoint: ./checked-out-script.sh

Вот собственно пример где я этот cделал: https://github.com/GpuZelenograd/memtest_vulkan/blob/main/.github/workflows/ci.yml

и предварительная единоразовая сборка Dockerfile в ghcr.io https://github.com/galkinvv/manycross2014/blob/main/.github/workflows/ci.yml

GPFault ★★★
()
Последнее исправление: GPFault (всего исправлений: 1)
Ответ на: комментарий от mx__

Сделайте контейнер без поля: FROM

Чтобы что? В FROM можно указать свой контейнер, какой тебе надо, в т.ч. пустой.

Можно конечно гланды через жопу удалять, но это плохая практика.

no-such-file ★★★★★
()
Ответ на: комментарий от mx__

Ты неправильно понял.

У меня есть контейнер, условно my-build-env, в нем нет Node.JS и тащить его туда я не хочу. В GitLab было так:

  1. GitLab Runner сам, без моего участия клонировал текущее репо, для которого запускается билд
  2. Скачивал мой образ
  3. Запускал контейнер с моим образом и монтировал ему папку с кодом
  4. Дальше контейнер с моим образом занимался сборкой
  5. GitLab брал результаты сборки и складывал их в артефакты по указанным путям

Ровно тоже самое я хочу сделать в GitHub Actions: я хочу взять свой образ для сборки без Node.JS, каким-то предварительным шагом склонировать код и подсунуть его на этап сборки.

Goganchic ★★
() автор топика
Ответ на: комментарий от fucpsy

Зачем тебе свой образ для сборки, чтобы усложнять процесс сборки для других?

Тоже вариант, не указывать при сборке какую то зависимость что уже есть в его образе.

P.S. А зачем юзающие github-actions обращают внимание на контейнеры?

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

Насколько я понял ему не нравится то что в github собирают контейнер докером который не умеет сам собирать контейнеры а может только клонировать.

Мдя? docker/build-push-action@v6 в помощь.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Ну думаю 2 - это для платного github, хотя могу и ошибаться …

Кстати я вот тут подумал, а как в Docker hub проверяется что в загруженном образе нет чего то плохого?

mx__ ★★★★★
()