Merge branch 'unstable' into stable

Author: markcda

CHANGELOG.md

@@ -7,6 +7,26 @@ 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).
 
+## [2.0.0] - 2025-11-06
+
+### Added
+
+- `from_cmd` variable type (for example, to get some passkeys via `curl` requests, etc.).
+- `desc` (description) field to `exists`, `exists_any` & `check_success` requirements to optionally describe steps for resolving them.
+- Independent variable setup for each pipelines (inside `depl edit project` UI -> any pipeline -> `Setup variables for the pipeline`).
+- `depl use` command to use content or templates from Deployer's storage.
+- `depl export/import registries` command (exports all actions and pipelines, and imports with merge).
+
+### Changed
+
+- Extended command-line options for `depl new content`, unified `edit`/`cat`/`rm` behavior.
+- Changed description output for `depl ls pipelines`.
+
+### Fixed
+
+- Custom storage path by `DEPLOYER_STORAGE_PATH` env variable wasn't applied by first.
+- Actions that used in a selected pipeline from the Registry are now synchronized with project config file.
+
 ## [2.0.0-beta-3] - 2025-10-21
 
 ### Changed
@@ -569,6 +589,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Build support.
 - TUI.
 
+[2.0.0]:          https://github.com/impulse-sw/deployer/compare/2.0.0-beta-3...2.0.0
 [2.0.0-beta-3]:   https://github.com/impulse-sw/deployer/compare/1.5.0-1...2.0.0-beta-3
 [1.5.0-1]:        https://github.com/impulse-sw/deployer/compare/1.5.0...1.5.0-1
 [1.5.0]:          https://github.com/impulse-sw/deployer/compare/1.4.4...1.5.0

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "deployer"
-version = "2.0.0-beta-3"
+version = "2.0.0"
 edition = "2024"
 
 [[bin]]

DOCS.md

@@ -17,15 +17,28 @@ Typically, it runs in a separate folder to save the cache while keeping the code
 Deployer is primarily a CLI utility. You can see help for any Deployer command by specifying the `-h` option. Here are some examples of the most common commands:
 
 ```bash
-depl new action                            # create an Action and put in Registry
-depl new pipeline                          # create a Pipeline and put in Registry
+depl new action                            # create an action and put in Registry
+depl new pipeline                          # create a pipeline and put in Registry
+depl new content                           # add some content in Deployer's storage folder
 depl new remote                            # add new remote host to Registry
+
+depl ls actions/pipelines/content/remote   # list all entities from Registries
+depl cat action/pipeline/content/remote    # display information about entiry from Registry
+depl rm action/pipeline/content/remote     # remove entity from Registry
+
 depl init                                  # init project, fill all attributes
 
+depl edit project                          # edit project
+depl edit .                                # (the same)
+
 depl with                                  # check compatibility and assign Pipeline to project,
                                            # also specify needed variables and artifacts
 
+depl use                                   # use some content from Deployer's storage
+
 depl run                                   # run default Pipeline
+depl                                       # (the same)
+
 depl run my-pipe                           # run specified `my-pipe` Pipeline
 depl run configure,build -o build-folder   # run `configure` and `build` Pipelines in a `build-folder`
 depl run -R my-remote my-pipe              # run `my-pipe` Pipeline on remote host `my-remote`
@@ -35,7 +48,7 @@ depl watch my-pipe                         # watch `my-pipe` Pipeline and re-run
 
 ### Console Interface (TUI)
 
-Deployer has support for a high-end terminal-based customizer, allowing you to forget about manually writing Actions and Pipelines for your projects. Just try to create an Action or Pipeline and Deployer will ask you about everything.
+Deployer has support for a high-end terminal-based customizer, allowing you to forget about manually writing actions and Pipelines for your projects. Just try to create an action or Pipeline and Deployer will ask you about everything.
 
 ### Logs
 
@@ -47,7 +60,7 @@ In the Deployer build caches folder, there is a `logs` folder that contains proj
 
 Action is the main entity of Deployer. Actions as part of pipelines are used to build, install, and deploy processes. However, an action itself cannot be assigned to a project, that's what pipelines are for (see below).
 
-In the Deployer's Action Registry or project's actions list, an action looks like a construction:
+In the Deployer's action Registry or project's actions list, an action looks like a construction:
 
 ```yaml
 info: upx@0.1.0
@@ -75,14 +88,17 @@ requirements:
       - /bin/upx
       - /usr/bin/upx
       - ~/.local/bin/upx
+    desc: "This is optional description with information about UPX installation steps."
   # if this path exists, the requirement is considered satisfied
   - type: exists
     path: /usr/bin/mold
-  # if this check is passed, the requirement will be considered satisfied (for details, see below - Action `Check`)
+    desc: "Only optional"
+  # if this check is passed, the requirement will be considered satisfied (for details, see below - action `Check`)
   - type: check_success
     command:
       cmd: /usr/bin/python -V
     success_when_found: "Python 3."
+    desc: "Only optional"
   # if a given remote host exists in the Registry, is accessible, and its Deployer version is identical to the version of the running Deployer,
   # the requirement will be considered satisfied
   - type: remote_accessible_and_ready
@@ -99,7 +115,7 @@ There are 7 action categories:
 6. Actions of synchronization build folders - from current to remote host `sync_to_remote` and vice versa `sync_from_remote`
 7. `interrupt` (when a user needs to perform some actions by hand before continue a pipeline)
 
-The concept of a custom command, a command for the terminal shell, is fundamental. The `custom`, `observe`, and the three main categories of Actions contain one or more custom commands inside.
+The concept of a custom command, a command for the terminal shell, is fundamental. The `custom`, `observe`, and the three main categories of actions contain one or more custom commands inside.
 
 #### 1.1. Custom command
 
@@ -268,7 +284,7 @@ When a patch is applied, Deployer displays the number of times it has been appli
 
 #### 1.4. Actions of synchronization run folders - from current to remote host `sync_to_remote` and vice versa `sync_from_remote`
 
-Sometimes you need to synchronize build files between remote hosts and the current host. For example, when some actions must be performed on one host, and some on another. To do this, you can use the built-in Actions `sync_to_remote` and `sync_from_remote`.
+Sometimes you need to synchronize build files between remote hosts and the current host. For example, when some actions must be performed on one host, and some on another. To do this, you can use the built-in actions `sync_to_remote` and `sync_from_remote`.
 
 #### 1.5. Other actions - `interrupt`, `observe` and `test`
 
@@ -344,9 +360,9 @@ Building and execution occur as follows:
 5. Deployer on the host machine runs Deployer in the container and performs complete pipeline execution.
 
 > [!NOTE]
-> 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`.
+> 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.
+> 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.
 
 > [!NOTE]
 > To prevent building Deployer before your project, switch to `shell` pipeline driver.

MIGRATIONS.md

@@ -20,7 +20,7 @@ Migrations will be applied automatically.
 
 ## From `1.4.1` to `1.4.2`
 
-1. Manually check all your `add_to_storage` Actions (`AutoVersionExtractFromRule`): them now look like this:
+1. Manually check all your `add_to_storage` actions (`AutoVersionExtractFromRule`): them now look like this:
 
 ```json
 [
@@ -57,10 +57,10 @@ Formally, you should now specify `type` field of `auto_version_rule` object.
 
 Migrations will be almost fully applied automatically on configuration save. Deployer will be able to work with old configuration formats (`"version": 2`).
 
-1. All Actions will be typed internally with `type` field and `snake_case` (example: `{ "type": "build", ... }`).
+1. All actions will be typed internally with `type` field and `snake_case` (example: `{ "type": "build", ... }`).
 2. `deploy-config.json` and `deploy-global.json` will be upgraded to `"version": 3`.
 3. Variables, requirements, placements and other structs are changed, see the documentation.
-4. Check Action will become Test, original Test will be migrated into PostBuild.
+4. Check action will become Test, original Test will be migrated into PostBuild.
 
 ### Need manual changes:
 
@@ -74,5 +74,5 @@ Migrations will be almost fully applied automatically on configuration save. Dep
 ## From `<=1.2.1` to `1.3.0`
 
 1. Edit `deploy-config.json` and rename `inplace_artifacts_into_project_root` to `place_artifacts_into_project_root`.
-2. Remove `tags` field inside your deploy-like and `Observe` Actions.
+2. Remove `tags` field inside your deploy-like and `Observe` actions.
 3. `deploy-config.json` and `deploy-global.json` will be upgraded to `"version": 2`.

README.md

@@ -96,7 +96,7 @@ actions:
     used: upx@0.1.0
 ```
 
-Note that you can change the inner content of Actions inside Pipelines, and also can change the inner content of Pipelines and their Actions if these Pipelines assigned to your project. The changes will not affect Actions and Pipelines from Deployer's Registries.
+Note that you can change the inner content of actions inside Pipelines, and also can change the inner content of Pipelines and their actions if these Pipelines assigned to your project. The changes will not affect actions and Pipelines from Deployer's Registries.
 
 You can view your actions and pipelines and get it in YAML by simple commands:
 
@@ -108,7 +108,7 @@ depl cat action upx@0.1.0
 depl cat pipeline pack@0.1.0
 ```
 
-And, of course, load Actions and Pipelines from YAML files by:
+And, of course, load actions and Pipelines from YAML files by:
 
 ```bash
 depl new action -f {your config}
@@ -122,7 +122,7 @@ depl init
 depl edit .
 ```
 
-You should add some actions and specify project variables that you'll use. For our example, add simple variable with `target/release/my-app` value. Also add `cargo-release@0.1.0` and `upx@0.1.0` actions from Actions Registry. And not forget to add `Cargo.lock` file and `target` folder to cache files to prevent syncing project folder cache with run folder cache (without specifying this; see `depl run --help` for more).
+You should add some actions and specify project variables that you'll use. For our example, add simple variable with `target/release/my-app` value. Also add `cargo-release@0.1.0` and `upx@0.1.0` actions from actions Registry. And not forget to add `Cargo.lock` file and `target` folder to cache files to prevent syncing project folder cache with run folder cache (without specifying this; see `depl run --help` for more).
 
 After all you will get this `.depl/config.yaml`:
 
@@ -199,7 +199,7 @@ depl run -fc
 # or explicitly specify the project pipeline's short name - `build-and-compress`
 depl run pack
 
-# create pipeline with `Observe` Action and start development server with auto-rebuild
+# create pipeline with `Observe` action and start development server with auto-rebuild
 depl watch build-and-deploy-devel
 ```
 

TODO.md

@@ -1,32 +1,3 @@
-# `deployer`'s 2.0 TODO list
+# `deployer`'s TODO list
 
-- [~] TUI for editing containered (Docker/Podman), Ansible, GitHub CI/CD and GitLab CI/CD options for Pipelines
-- [x] Replace complete `RemoteHost` definitions from `ansible_opts` for their shortnames
-- [x] Add `depl cd` command to change current directory to one of run directories
-- [~] Make `depl export` command:
-  1. [x] for exporting Pipelines to `bash` scripts
-  2. [ ] for exporting (and importing with merging) Actions & Pipelines Registries
-  3. [x] for exporting Pipelines to CI/CD (GitHub Actions & GitLab CI) configurations
-- [x] Add `--skip N` argument to skip N Actions inside selected Pipelines, if you exactly know that they have no need to re-run after changes
-- [x] Add `--no-clear` argument to disable screen clear on `run`/`watch`
-- [~] Go to more declarative way to define project configuration (ver. 6 & Deployer v2.0)
-  1. [x] Remove targets, programming languages and actions variability
-  2. [x] Rename `Actions` & `Pipelines` to `actions` and `pipelines`
-  3. [x] Split `configs.rs` to `project.rs` and `globals.rs`
-  4. [x] Allow to both use and define actions in pipelines. Used actions should be defined inside project configuration
-  5. [x] Fix all traits and TUI interface
-  6. [x] Fix action setup:
-    > Action setup depends on command definition of placeholders and replacements. I think I should remove replacements completely
-    > and add `with` field to `UsedAction` as `BTreeMap<String, Variable>`, e.g. placeholder-variable pairs.
-- [x] Remove `artifacts` field completely (`artifacts_placements` is enough)
-- [x] Fix `depl watch` with no `artifacts` folder ignoring
-- [x] Remove automigrator with `MIGRATIONS.md` autoreference:
-  1. [-] Add `depl migrate` command
-  2. [x] Remove `configs` source
-  3. [x] Refine `read` functions from `crate::rw` module
-  4. [x] Add prompt on `crate::rw` to read `MIGRATIONS.md`
-- [-] Make `DEPLOYER_DRIVER` env variable support to define executor: bash on itself or Deployer implementation (default)
-- [x] Make `driver` pipeline option support to define executor: bash on itself or Deployer implementation (default):
-  1. [x] For Pipelines
-  2. [x] For containered builds & runs
-  3. [x] For Ansible runs
+- [~] TUI for editing containered (Docker/Podman), Ansible, GitHub CI/CD and GitLab CI/CD options for pipelines