Пропустить сборку уже существующего локального образа. Это так сложно?

Question

[Дмитрий]

Для сборки бандла в CI/CD используется настроенный образ, сохраненный в Container Registry. Задача оптимизации - создавать образ, если его нет (например, для новой ветки) и использовать имеющийся, если он есть (пропускать сборку).
Это что, такая нетривиальная задача с кучей подводных камней?

PS:
Речь идет о некоторой общей задаче, в которой по "внешнему" условию (наличие образа, прогноз погоды и т.д.) нужно выполнять или пропускать определенную задачу (job) или целый набор задач.

PS2:
Совсем забыл, что есть и второе условие: пересобирать образ если изменился Dockerfile.

Comments

[Sand]

Задача как задача. Контекста не хватает в вопросе

[Дмитрий]

Какой еще контекст нужен? Есть образ - пропускаем задачу, нет образа - выполняем.

[Wexter]

Дмитрий, в чём проблема сделать эту проверку внутри задачи и завершать при наличии образа?

[Дмитрий]

Wexter, я тоже уже подумал: да хрен с ней - с общей задачей. Решу конкретную. Именно так, как вы и предлагаете, но нет - хренушки. А все из-за второго правила, о котором я призабыл... Вот так примерно должно быть:

rules:
    - if: $NO_IMAGE
    - changes:
        - .gitlab/Dockerfile

[Alexey Dmitriev]

И в чем проблема? Непонятно, что мешает сделать в задаче или отдельным правилом if else с использованием docker manifest inspect.

[Владислав Лысков]

какая-то дикая постановка вопроса

[Дмитрий]

Alexey Dmitriev, никаких проблем. Как к этому добавить проверку на изменение Dockerfile?

[Дмитрий]

Владислав Лысков, по-моему задача предельно простая - собирать образ не при каждом пуше, а только если его нет или изменился Dockerfile. Вы же согласитесь, что образы бывают очень разные...

[Дмитрий]

Alexey Dmitriev, Сейчас я подумал, что можно разделить на два отдельных стейджа: в первом проверять Dockerfile, а во втором наличие образа. Тогда пластинка заиграет.
Но все-таки это решение конкретной задачи, где условия это позволяют... а что если задач под условием десятки...

[Alexey Dmitriev]

Дмитрий, что значит конкретную? Можно сделать задачу по проверке образа, можно сделать правило по проверке образа и вызывать их проверку в каждой нужной задаче. Это выглядит общим решением.

[Дмитрий]

Alexey Dmitriev,

Можно сделать задачу по проверке образа, можно сделать правило по проверке образа и вызывать их проверку в каждой нужной задаче.

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

[Alexey Dmitriev]

Дмитрий, например через needs:

needs:
    - job: check_image

Либо просто в задаче проверки образа создаете любой артефакт, а в задаче сборки проверяете его наличие.

[Дмитрий]

Alexey Dmitriev, артифакты - это интересно, но мы не можем проверять их наличие в rules.

rules:exists cannot search for the presence of artifacts, because rules evaluation happens before jobs run and artifacts are fetched.

Таким образом проверка может быть только внутри скрипта, а это значит, что возникают сложности при наличии нескольких правил запуска задания (например, изменение Dockerfile). Кроме того мы теряем возможность пользоваться UI плюшками вроде when: manual.

[Владимир Мясников]

Дмитрий, динамически добавить/исключить задачу из текущего pipeline на основе артефактов, вычисляемых в самом pipeline, технически невозможно, так как набор задач определяется в момент порождения pipeline, но можно решить это с использованием downstream pipeline.

Например, через dependent parent-child pipeline:
1. На уровне parent pipeline определить переменную, по которой будет определяться необходимость дальнейшего запуска сборки.
2. В trigger задаче передать значение переменной в порожденный pipeline сборки.
3. В задачах дочернего pipeline использовать значение переменной в `rules`, чтобы задача была либо не была включена в дочерний pipeline.