Merge branch 'unstable' into stable

Author: markcda

CHANGELOG.md

@@ -7,6 +7,16 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.4.0-beta-5] - 2025-02-17
+
+### Changed
+
+- Made Deployer ignore some types of Actions inside containers.
+
+### Fixed
+
+- `executor` field optionality, empty regexes in `Test` Action, output composing.
+
 ## [1.4.0-beta-4] - 2025-02-16
 
 ### Added
@@ -437,6 +447,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Build support.
 - TUI.
 
+[1.4.0-beta-5]:   https://github.com/impulse-sw/deployer/compare/1.4.0-beta-5...1.4.0-beta-5
 [1.4.0-beta-4]:   https://github.com/impulse-sw/deployer/compare/1.4.0-beta-3...1.4.0-beta-4
 [1.4.0-beta-3]:   https://github.com/impulse-sw/deployer/compare/1.4.0-beta-2...1.4.0-beta-3
 [1.4.0-beta-2]:   https://github.com/impulse-sw/deployer/compare/1.4.0-beta-1...1.4.0-beta-2

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "deployer"
-version = "1.4.0-beta-4"
+version = "1.4.0-beta-5"
 edition = "2024"
 
 [dependencies]

DOCS.en.md

@@ -694,12 +694,22 @@ In addition, if your Pipelines need to manage conflicting cache versions (for ex
 
 #### 2.1. Containerized assembly and execution, as well as strategies
 
-The deployment supports the build and execution of projects in containerized environments with the ability to extract artifacts to the project folder. This can be useful in cases where you need to build a project for other platforms and/or environments.
+Since Deployer can execute any commands, it can also automate deployment in containers and clusters using Docker and Kubernetes-like platforms. But most interestingly, Deployer provides automation for building and running your Pipelines in Docker and Podman containers with automatic `Dockerfile` generation. Artifacts will also be automatically extracted and placed in the project folder. Containerized building can be useful in cases where building for other platforms or in a different environment is required.
 
-In addition, the Deployer allows you to specify basic images, a list of commands for installing dependencies and configuring the image, as well as strategies for saving caches. Collectively, this allows you to generate information for `Dockerfile` images automatically.
+In this regard, Deployer allows additional functions (see below).
+
+Building and execution occur as follows:
+
+1. An image is formed to build Deployer for the desired platform (for executing Pipelines based on the image).
+2. Deployer is built.
+3. An image is formed to build the project for the desired platform - with necessary dependencies and other commands that can be specified independently.
+4. If build caching strategies are specified, Deployer performs the build and saves caches.
+5. Deployer on the host machine runs Deployer in the container and performs complete Pipeline execution.
 
 > [!NOTE]
-> Deployer versions 1.4.0-beta-1/1.4.0-beta-2 only support Pipeline launch in Docker containerized environments.
+> When building in containers, Deployer does not support Actions `interrupt`, `observe`, `add_to_storage` and `use_from_storage`, and when running - Actions `add_to_storage` and `use_from_storage`.
+>
+> To solve problems of synchronizing files or performing I/O operations, you can use a Pipeline with containerized build options inside another Pipeline, which can then use the Actions you need.
 
 Let's look at an example of a containerized Pipeline:
 
@@ -794,23 +804,22 @@ Let's look at an example of a containerized Pipeline:
           "COPY rust-toolchain.toml .",
           "COPY .docker-fake-files/rust/lib.rs src/lib.rs",
           "COPY .docker-fake-files/rust/main.rs src/main.rs",
-          "COPY Cargo.toml .",
-          "COPY deploy-config.json ."
+          "COPY Cargo.toml ."
         ],
         "pre_cache_cmds": [
-          "RUN /app/deployer run containered --current --containered --no-pipe"
+          "DEPL"
         ]
       },
       {
         "copy_cmds": [
-          "COPY src/ src/"
+          "COPY src/ src/",
+          "COPY DOCS.en.md .",
+          "COPY DOCS.ru.md ."
         ],
         "pre_cache_cmds": [
-          "COPY DOCS.en.md .",
-          "COPY DOCS.ru.md .",
           "RUN touch src/main.rs",
           "RUN touch src/lib.rs",
-          "RUN /app/deployer run containered --current --containered --no-pipe"
+          "DEPL"
         ]
       }
     ]
@@ -819,34 +828,29 @@ Let's look at an example of a containerized Pipeline:
 }
 ```
 
-The only difference is the addition of the `containered_opts` field, which automatically forces the Deployer to execute this Pipeline in a containerized environment.
+The only difference is adding the `containered_opts` field, which automatically makes Deployer execute this Pipeline in a containerized environment.
 
 - `base_image` - you can specify the base image for building the project (default is `ubuntu:latest`)
-- `preflight_cmds` - a list of commands for installing the environment correctly
-- `build_deployer_base_image`, `preflight_deployer_build_deps` and `deployer_build_cmds` - base image, configuration commands and commands for building the Deployer itself
-- `cache_strategies` - caching strategies during build stage
+- `preflight_cmds` - list of commands for proper environment setup
+- `build_deployer_base_image`, `preflight_deployer_build_deps` and `deployer_build_cmds` - base image, setup commands, and commands for building Deployer itself
+- `cache_strategies` - caching strategies during build
+- `use_containerd_local_storage_cache` - when building in Docker with enabled `containerd` feature in `/etc/docker/daemon.json`, allows saving image cache in the Pipeline execution folder, which simplifies cache cleanup
+- `prevent_metadata_loading` - prevents reconnecting to registries and searching for a new image when an old one is available (allows building and running Pipelines in containers without Internet access)
+- `executor` - allows specifying the build and run executor (default is Docker, specify `podman` to use Podman)
 
-Since the Deployer is needed in a containerized environment, check the compatibility of the Deployer and the environment by launching the Pipeline. If the Deployer is built with Python support, it is best to use identical base images.
+Since Deployer is needed in a containerized environment, check Deployer and environment compatibility by running the Pipeline. If Deployer is built with Python support, it's best to use identical base images.
 
-To keep the build cache, rather than constantly rebuilding the Pipeline from scratch, it is recommended to specify caching strategies. They are executed when building a containerized environment. Available fields:
+To preserve build caches rather than constantly rebuilding the Pipeline from scratch, it's recommended to specify caching strategies. They are executed when building the containerized environment. Available fields:
 
-- `fake_content` - a field for syncing content to replace existing files (works the same way as `use_from_storage`, but does not support `latest` tags)
-- `copy_cmds` - commands for copying source code to an image
-- `pre_cache_cmds` - commands for pre-caching
+- `fake_content` - field for content synchronization to substitute existing files (works like `use_from_storage` but doesn't support `latest` tags)
+- `copy_cmds` - commands for copying source code into the image
+- `pre_cache_cmds` - commands for preliminary caching
 
-Caching strategies are suitable for implementing multi-stage builds. In the above example, there is a two-stage build for a Rust project, which first requires copying the real `Cargo.toml` and fake `lib.rs `and `main.rs `to compile all the dependencies of the project first, and then copies the real source code `src/` and updates the timestamps `RUN touch src/main.rs & touch src/lib.rs` to then build the project without having to rebuild dependencies. In this case, the dependency cache will be used until `Cargo.toml` is edited.
+If you need to execute a Pipeline as a preliminary caching command, specify the `"DEPL"` command. The containerized Pipeline configuration will be added to the container automatically.
 
-To rebuild containered environment from scratch, run Deployer with flag `-f`/`--fresh`.
+Caching strategies are suitable for implementing multi-stage builds. In the example above, a two-stage build for a Rust project occurs, which first requires copying the real `Cargo.toml` and fake `lib.rs` and `main.rs` to first compile all project dependencies, and then copies the real source code `src/` and updates timestamps `RUN touch src/main.rs & touch src/lib.rs` to then build the project without needing to rebuild dependencies. In this case, the dependencies cache will be used until `Cargo.toml` is edited.
 
-Additionally Deployer supports caching for images and their metadata (to avoid repeated requests to the server when the image is already present in the system) and caching files in local storage (in the pipeline folder) (to do this, it is necessary to activate the `containerd` feature in the file `/etc/docker/daemon.json`):
-
-```json
-"containered_opts": {
-  ...,
-  "use_containerd_local_storage_cache": true,
-  "prevent_metadata_loading": true
-}
-```
+To rebuild the environment from scratch, run Deployer with the `-f`/`--fresh` flag.
 
 ### <a id="other-entities">3. Other entities</a>
 

DOCS.ru.md

@@ -487,8 +487,7 @@ deployer new content
     "show_bash_c": false,
     "only_when_fresh": false
   },
-  "success_when_found": "some rust regex",
-  "success_when_not_found": null
+  "success_when_found": "some rust regex"
 }
 ```
 
@@ -695,12 +694,22 @@ deployer new content
 
 #### 2.1. Контейнеризированная сборка и выполнение, а также стратегии
 
-Деплойер поддерживает сборку и выполнение проектов в контейнеризированных окружениях с возможностью извлечения артефактов в папку проекта. Это может быть удобным в тех случаях, когда требуется сборка проекта под другие платформы и/или окружения.
+Поскольку Деплойер может выполнять любые команды, он также может автоматизировать выполнение развёртывания в контейнерах и кластерах при помощи Docker- и Kubernetes-подобных платформ. Но, что самое интересное, Деплойер предоставляет автоматизацию сборки и запуска ваших Пайплайнов в контейнерах Docker и Podman с автоматической генерацией `Dockerfile`. Артефакты также будут извлечены автоматически и помещены в папку проекта. Контейнеризированная сборка может быть полезной в тех случаях, когда требуется сборка под другие платформы или в другом окружении.
 
-Помимо этого, Деплойер позволяет указывать базовые образы, список команд для установки зависимостей и настройки образа, а также стратегии для сохранения кэшей. Совокупно это позволяет генерировать информацию для образов `Dockerfile` автоматически.
+В этом плане Деплойер позволяет дополнительные функции (см. ниже).
+
+Сборка и выполнение происходят следующим образом:
+
+1. Формируется образ для сборки Деплойера под нужную платформу (для выполнения Пайплайнов на базе образа).
+2. Собирается Деплойер.
+3. Формируется образ для сборки проекта под нужную платформу - с необходимыми зависимостями и прочими командами, которые можно указать самостоятельно.
+4. Если указаны стратегии кэширования сборки, Деплойер производит сборку и сохраняет кэши.
+5. Деплойер на машине-хосте запускает Деплойер в контейнере и производит полное выполнение Пайплайна.
 
 > [!NOTE]
-> В версиях Деплойера 1.4.0-beta-1/1.4.0-beta-2 есть поддержка только запуск Пайплайнов в контейнеризированных окружениях Docker.
+> При сборке в контейнерах Деплойер не поддерживает Действия `interrupt`, `observe`, `add_to_storage` и `use_from_storage`, а при запуске - Действия `add_to_storage` и `use_from_storage`.
+> 
+> Для решения проблем синхронизации каких-то файлов или выполнения операций ввода-вывода вы можете использовать Пайплайн с опциями контейнеризированной сборки внутри другого Пайплайна, который уже сможет использовать нужные вам Действия.
 
 Посмотрим на пример контейнеризированного Пайплайна:
 
@@ -796,22 +805,21 @@ deployer new content
           "COPY .docker-fake-files/rust/lib.rs src/lib.rs",
           "COPY .docker-fake-files/rust/main.rs src/main.rs",
           "COPY Cargo.toml .",
-          "COPY deploy-config.json ."
         ],
         "pre_cache_cmds": [
-          "RUN /app/deployer run containered --current --containered --no-pipe"
+          "DEPL"
         ]
       },
       {
         "copy_cmds": [
-          "COPY src/ src/"
+          "COPY src/ src/",
+          "COPY DOCS.en.md .",
+          "COPY DOCS.ru.md ."
         ],
         "pre_cache_cmds": [
-          "COPY DOCS.en.md .",
-          "COPY DOCS.ru.md .",
           "RUN touch src/main.rs",
           "RUN touch src/lib.rs",
-          "RUN /app/deployer run containered --current --containered --no-pipe"
+          "DEPL"
         ]
       }
     ]
@@ -826,6 +834,9 @@ deployer new content
 - `preflight_cmds` - список команд для правильной установки окружения
 - `build_deployer_base_image`, `preflight_deployer_build_deps` и `deployer_build_cmds` - базовый образ, команды для настройки и команды для сборки самого Деплойера
 - `cache_strategies` - стратегии кэширования при сборке
+- `use_containerd_local_storage_cache` - при сборке в Docker и включенной фиче `containerd` в `/etc/docker/daemon.json` позволяет сохранять кэш образов в папке выполнения Пайплайна, что упрощает очистку кэша
+- `prevent_metadata_loading` - предотвращает повторное подключение к регистрам и поиск нового образа, когда доступен старый (позволяет осуществлять сборку и запуск Пайплайнов в контейнерах без доступа к Интернету)
+- `executor` - позволяет указать исполнителя сборки и запуска (по умолчанию - Docker, для использования Podman укажите `podman`)
 
 Поскольку Деплойер нужен в контейнеризированном окружении, проверяйте совместимость Деплойера и окружения путём запуска Пайплайна. Если Деплойер собран с поддержкой Python, лучше всего использовать идентичные базовые образы.
 
@@ -835,20 +846,12 @@ deployer new content
 - `copy_cmds` - команды для копирования исходного кода в образ
 - `pre_cache_cmds` - команды для предварительного кэширования
 
+Если в качестве команды предварительного кэширования нужно выполнить Пайплайн, укажите команду `"DEPL"`. Конфигурация контейнеризированного Пайплайна будет добавлена в контейнер автоматически.
+
 Стратегии кэширования подходят для реализации многостадийных сборок. В указанном выше примере происходит двухстадийная сборка для Rust-проекта, которая сначала требует копирования реального `Cargo.toml` и фейковых `lib.rs` и `main.rs`, чтобы сначала скомпилировать все зависимости проекта, а потом уже копирует реальный исходный код `src/` и обновляет штампы времени `RUN touch src/main.rs & touch src/lib.rs`, чтобы затем собрать проект без необходимости пересборки зависимостей. В этом случае будет использоваться кэш зависимостей до тех пор, пока `Cargo.toml` не будет отредактирован.
 
 Для пересборки окружения с нуля запустите Деплойер с флагом `-f`/`--fresh`.
 
-Деплойер дополнительно поддерживает опцию кэширования для образов и их метаданных (чтобы избежать повторного обращения к серверу, когда образ уже имеется в системе) и опцию кэширования файлов в локальном хранилище (в папке пайплайна) (для этого необходимо активировать `containerd`-фичу в файле `/etc/docker/daemon.json`):
-
-```json
-"containered_opts": {
-  ...,
-  "use_containerd_local_storage_cache": true,
-  "prevent_metadata_loading": true
-}
-```
-
 ### <a id="other-entities">3. Другие сущности</a>
 
 Одной из самых важных сущностей являются переменные. Они одновременно являются и хранителями ваших секретов, и теми самыми динамическими сущностями, которые могут поменять исход выполнения Пайплайна. Пример простой переменной:

MIGRATIONS.md

@@ -1,5 +1,7 @@
 # Migrations guide
 
+> Actual configs' version: `4`.
+
 ## From `1.4.0-beta-3` to `1.4.0-beta-4`
 
 1. Manually check all your configuration files for programming languages and targets' OSes. Replace `null` values with strings in the lower register (for example, `"rust"`, `"linux"`, etc.).