{"id":15083686,"url":"https://github.com/alexanderbazhenoff/universal-wrapper-pipeline-settings","last_synced_at":"2026-02-03T05:01:26.167Z","repository":{"id":155505585,"uuid":"618520545","full_name":"alexanderbazhenoff/universal-wrapper-pipeline-settings","owner":"alexanderbazhenoff","description":"Yaml settings and format description for Universal Wrapper Pipeline.","archived":false,"fork":false,"pushed_at":"2024-07-03T23:38:32.000Z","size":176,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-06-24T06:05:08.159Z","etag":null,"topics":["cicd","jenkins-pipeline","yaml"],"latest_commit_sha":null,"homepage":"https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/alexanderbazhenoff.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-03-24T16:41:38.000Z","updated_at":"2024-07-03T23:38:28.000Z","dependencies_parsed_at":null,"dependency_job_id":"0067cee7-9717-49a1-9b3b-0fea851ba6e9","html_url":"https://github.com/alexanderbazhenoff/universal-wrapper-pipeline-settings","commit_stats":{"total_commits":148,"total_committers":1,"mean_commits":148.0,"dds":0.0,"last_synced_commit":"cf4aa0cc6f621b649157b1f439329c5dcd5529e0"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/alexanderbazhenoff/universal-wrapper-pipeline-settings","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexanderbazhenoff%2Funiversal-wrapper-pipeline-settings","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexanderbazhenoff%2Funiversal-wrapper-pipeline-settings/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexanderbazhenoff%2Funiversal-wrapper-pipeline-settings/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexanderbazhenoff%2Funiversal-wrapper-pipeline-settings/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/alexanderbazhenoff","download_url":"https://codeload.github.com/alexanderbazhenoff/universal-wrapper-pipeline-settings/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/alexanderbazhenoff%2Funiversal-wrapper-pipeline-settings/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29033716,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-03T02:28:16.591Z","status":"ssl_error","status_checked_at":"2026-02-03T02:27:48.904Z","response_time":96,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cicd","jenkins-pipeline","yaml"],"created_at":"2024-09-25T06:30:59.133Z","updated_at":"2026-02-03T05:01:26.119Z","avatar_url":"https://github.com/alexanderbazhenoff.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003c!-- markdownlint-disable MD001 MD007 MD025 MD033 MD041 --\u003e\n\u003c!-- docs-ci-cut-begin --\u003e\n\u003cdiv align='center'\u003e\n\n# Settings file format description for [Universal Wrapper Pipeline](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline)\n\u003c!-- markdown-link-check-disable --\u003e\n[![MegaLinter](https://github.com/alexanderbazhenoff/universal-wrapper-pipeline-settings/actions/workflows/mega-linter.yml/badge.svg?branch=main)](https://megalinter.io/)\n[![Wiki CI](https://github.com/alexanderbazhenoff/universal-wrapper-pipeline-settings/actions/workflows/wiki-ci.yml/badge.svg?branch=main)](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline/wiki)\n[![Release for Jenkins](https://img.shields.io/github/v/release/alexanderbazhenoff/jenkins-universal-wrapper-pipeline?label=release%20for%20Jenkins)](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline/releases)\n[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](https://makeapullrequest.com)\n[![GitHub License](https://img.shields.io/github/license/alexanderbazhenoff/universal-wrapper-pipeline-settings)](LICENSE)\n[![Tweet](https://img.shields.io/twitter/url/http/shields.io.svg?style=social)](https://twitter.com/intent/tweet?text=Create+your+pipelines+easier+and+faster%21%20\u0026url=https://github.com/alexanderbazhenoff/universal-wrapper-pipeline-settings\u0026hashtags=devops,cicd,jenkins,ansible,yaml)\n\u003c!-- markdown-link-check-enable --\u003e\n\u003cspan style=\"font-size:0.8em;\"\u003e[**English**](README.md) • [Russian](README_RUS.md)\u003c/span\u003e\n\u003c/div\u003e\n\u003c!-- docs-ci-cut-end --\u003e\n\nThe Universal Wrapper Pipeline configuration file must be written according to all\n[yaml syntax standards](https://yaml.org/). One single settings file for one single wrapper pipeline. But exceptions\nusing [regular expressions](#example-1) in pipeline names are also possible: one configuration file can be used in\nseveral copies of pipeline with different names. The general structure of configuration files is described in section\n['Configuration files main keys'](#configuration-files-main-keys).\n\n# Configuration files names\n\nConfiguration files should be named as `pipeline-name.yaml` and placed in `settings/` folder of repository (can be\nchanged by `SettingsRelativePathPrefix` pipeline constant or `JUWP_RELATIVE_PATH_PREFIX` environment variable).\nPrefixes and postfixes are allowed in the pipeline name, to remove them and bring configuration file names to uniformity\nthere is a `PipelineNameRegexReplace` pipeline constant (or `JUWP_PIPELINE_NAME_REGEX_REPLACE` environment variable).\n\n#### Example 1\n\nPipeline constant looks like:\n\n```groovy\nfinal List PipelineNameRegexReplace = ['^(admin|devops|qa)_']\n```\n\nSo pipelines with `admin_example-pipeline`, `devops_example-pipeline` and `qa_example-pipeline` names run the only one\n`example-pipeline.yaml` configuration file.\n\n*Regular expressions and setting the path inside the repository are intended to simplify structuring configuration files\ninside the repository and customization on different needs. You may leave a path by default and regular expressions as\nempty, then configuration files should be placed as: `settings/admin_example-pipeline.yaml`,\n`settings/devops_example-pipeline.yaml` and `settings/qa_example-pipeline.yaml`.\n\n# Configuration files main keys\n\nThe configuration file consists of several keys, each of which divides it into several “sections”:\n\n```yaml\n---\n\nparameters:\n  # Keys in parameters dict...\nstages:\n  # Keys in stages dict...\nactions:\n  # Keys in actions dict...\nscripts:\n  # Keys in scripts dict...\nplaybooks:\n  # Keys in playbooks dict...\ninventories:\n  # Keys in inventories dict...\n```\n\n- [**parameters**](#parameters-key) `[dict]` *(required for parametrized pipelines)* - pipeline parameters, those that\n  you set in GUI before a pipeline run.\n- [**stages**](#stages-key) `[list]` *(mandatory)* - list of pipeline stages.\n- [**actions**](#actions-key) `[dict]` *(mandatory)* - action defining that can also refer to a playbook and inventory\n  inside [playbooks](#playbooks-key) and ['inventories'](#inventories-key) keys, or to a script from\n  ['scripts'](#scripts-key).\n- [**scripts**](#scripts-key) `[dict]` *(optional)* - a key containing scripts that will be launched when the\n  corresponding action is executed.\n- [**playbooks**](#playbooks-key) `[dict]` *(optional)* - a key containing ansible playbooks that will be launched\n  when the corresponding action is executed.\n- [**inventories**](#inventories-key) `[dict]` *(optional)* - a key containing ansible inventories that will be used\n  together with playbooks of the same name when executing the action. If there is at least one playbook in the\n  [playbooks](#playbooks-key) key, the presence of ['inventories'](#inventories-key) key and at least one inventory with\n  the name `default` are required.\n\n## 'parameters' key\n\nThe key contains pipeline parameters, presented as a dictionary, which are divided into three types:\n\n- [**required**](#required) `[list]` - mandatory pipeline parameters, without setting the values of which the current\n   pipeline run will end with an error. They are described inside the key of the same name [required](#required), nested\n   in the key [parameters](#parameters-key):\n\n  ```yaml\n  parameters:\n    required:\n  ```\n\n- [**optional**](#optional) `[list]` - optional; their empty values will neither warnings results nor cause the\n  pipeline to stop with an error. Similar as 'required' these parameters are described in the key with corresponding\n  name nested in the 'parameters' key.\n- [**built-in**](#built-in-pipeline-parameters) - 'built-in' pipeline parameters: `SETTINGS_GIT_BRANCH`, `NODE_NAME`,\n  `NODE_TAG`, `UPDATE_PARAMETERS`, `DRY_RUN` and `DEBUG_MODE`. These parameters are already built directly into the\n  pipeline code (inside the `BuiltinPipelineParameters` constant). There is no need to set them in the configuration\n  file, but they can be used in pipeline configuration file to assign their values to other pipeline variables (see\n  `assign` in [Example 2](#example-2)), or use in playbooks and scripts.\n\nIf at least one of the pipeline parameters specified in the configuration file does not match the current pipeline\nparameters, then all parameters will be resynchronized with the parameters in the configuration file. The checking is\nmade by parameter names only; type, default values, and other parameter keys are ignored.\n\nThe Pipeline may not have required parameters (key [required](#required)), and all parameters can be placed in\n[optional](#optional) key (see [Example 4](#example-4)), or not to have any parameters at all: in this case, only the\nempty 'parameters' key should be specified. Any required parameter can also become optional without moving it to the\nappropriate dictionary [`optional`](#optional) by specifying additional key options [`on_empty`](#required) (see\n[Example 2](#example-2)).\n\n### required\n\nThe [required](#required) key is located inside the [parameters](#parameters-key) key and consists of a list of\npipeline parameters, each of which has the following keys:\n\n- **name** `[string]` *(mandatory)* - pipeline parameter name.\n- **type** `[string]` *(mandatory)* - a parameter type that fully corresponds to the standard parameter types for\n  a pipeline. Can be `string` (string), `text` (multiline), `password` (password), `choice` (selection), `boolean`\n  (logical). Specifying the type of the pipeline parameter is mandatory, although in some cases it is possible to\n  autodetect the type and display the appropriate warning to fix.\n- **description** `[string]` *(mandatory)* - description of the pipeline parameter, similar to what is set in the\n  pipeline settings graphical interface.\n- **default** [depends on `type`] *(optional and compatible with a choice parameter type)* - default value of the\n  pipeline parameter. If the default value and the pipeline parameter are not specified, then when running pipeline\n  the parameter value will be equivalent to `false` for *boolean* and an empty field for string (including *password*)\n  parameters.\n- **choices** `[list]` *(compatible with and required for a choice parameter type only)* - possible selection options\n  for choice parameters.\n- **trim** `[boolean]` *(optional and compatible with a string parameter type only)* - remove leading and trailing\n  spaces in the parameter string value. Default is `false`.\n- **on_empty** `[dict]` *(optional)* - options for specifying actions if the parameter when starting the pipeline is not\n   specified (or empty) (see [Example 2](#example-2)). Contains the following nested keys:\n\n    - **assign** `[string]` *(optional)* - the name of the pipeline parameter which value will be assigned when\n      parameter is not specified (empty). It is also possible to assign environment variables, and therefore Jenkins or\n      Teamcity variables: `$NODE_NAME`, `$JOB_NAME`, etc. (see [Variable substitution](#variable-substitution)).\n    - **fail** `[boolean]` *(optional, not compatible with the `warn` key)* - a switch to terminate the pipeline with an\n      error if the pipeline parameter is not specified. If the pipeline parameter is required and nested in\n      [required](#required), then there is no need to specify `fail: True`.\n    - **warn** `[boolean]` *(optional, not compatible with the `fail` key)* - a switch to display a warning, but\n      continue pipeline execution if the parameter is not specified.\n\n  If the pipeline parameter is inside [required](#required) and the `on_empty` key is not specified, then an empty\n  value for such a parameter will terminate the pipeline with an error.\n- **regex** `[string, or list]` *(optional)* - a regular expression, or a list of regular expression strings that will\n  be combined into a single string to check the pipeline parameter: if the parameter value does not match the regular\n  expression, the current pipeline run will stop with an error.\n- **regex_replace** `[dictionary]` *(optional)* - options to control the replacement of pipeline parameter values that\n  will be performed when substituting or setting pipeline parameter values. Available only for string (except\n  *password*) parameters. Contains the following nested keys:\n\n    - **regex** `[string]` *(mandatory)* - regular expression to search for when replacing the contents of a pipeline\n      parameter.\n    - *(optional)* - replace matches with the content specified in this key (see [Example 3](#example-3)). If the value\n      or `to` key is not specified, then all regular expressions matches specified in the `regex` key will be removed.\n\n  Replacement of pipeline parameter values (with the `regex_replace` key data) is performing at the very beginning of\n  the pipeline launch: after possible substitution of other pipeline parameter values (`on_empty` key data) and checking\n  these values for `regex` match. Thus, `regex` specifies conditions for checking the original values after possible\n  substitution, and `regex_replace` specifies parameters for changing their values of pipeline parameters for usage in\n  [pipeline stages](#stages-key) (see [Example 3] (#example-3)).\n\n#### Example 2\n\n```yaml\n# This Pipeline contains three parameters in the `required` key, but only the `LOGIN`\n# parameter is required, omitting which (an empty parameter value) will cause the\n# pipeline to fail. If the `PASSWORD` parameter is not specified, then only a warning will\n# appear in the console then the pipeline will continue executing, but if `LOGIN_2` is not\n# specified, then only a warning will be issued, then the value will be taken from the\n# pipeline's `LOGIN` parameter.\n\nparameters:\n  required:\n    - name: LOGIN\n      type: string\n    - name: LOGIN_2\n      type: string\n      on_empty:\n        assign: $LOGIN\n        warn: True\n    - name: PASSWORD\n      type: password\n      on_empty:\n        warn: True\n```\n\n#### Example 3\n\n```yaml\n# A part of the configuration file with the required pipline parameter `IP_ADDRESSES`,\n# where spaces will be replaced with 'line feed' for substitution inside ansible inventory\n# (not included in example, but means). Also pay attention to the syntax in the value of the\n# 'to' field in the regex_replace key of `IP_ADDRESSES` parameter. If pipeline stages use this\n# variable, its value will also be formatted: IPs (or hosts) will be separated by line breaks\n# rather than by spaces.\n\nparameters:\n  required:\n    - name: IP_ADDRESSES\n      type: string\n      description: Space separated IP or DNS list of the host(s).\n      regex_replace:\n        regex: ' '\n        to: \"\\\\\\n\"\n```\n\n### optional\n\nThe [optional](#optional) key is located inside the [parameters](#parameters-key) key and consists of a list of optional\npipeline parameters. The structure and list of keys is similar to the [required](#required) key, except that there is no\nneed to set `on_empty` key values here, since they will be ignored. Thus, only optional pipeline parameters are set in\nthis key. There is no way to control the pipeline behavior if these parameters are empty.\n\n#### Example 4\n\n```yaml\n# A part of the pipeline configuration file containing only optional parameters `ONE` and\n# `TWO`.\n\nparameters:\n  optional:\n    - name: ONE\n      type: string\n      description: \u003e-\n        Description of parameter ONE which type is string and default value is 'something'.\n      default: something\n    - name: TWO\n      type: choice\n      description: \u003e-\n        Description of parameter TWO which type is choices.\n        TWO parameter includes three choices ('one', 'two' and 'three')\n      choices:\n        - one\n        - two\n        - three \n```\n\n## 'stages' key\n\nThe key contains a list of pipeline stages, each element of which has the following keys:\n\n- **name** `[string]` *(mandatory)* - name of the pipeline stage. [Variable substitution](#variable-substitution) is\n  possible as a key value (see [Example 22](#example-22)).\n- **parallel** `[boolean]` *(optional)* - a switch, the setting of which leads to parallel launch the list of actions\n  (the `actions` key) at the current stage (see [Example 6](#example-6)). Default is `false`.\n- **actions** `[list]` *(mandatory)* - list of actions in current stage, each element of which has keys:\n\n  - **before_message** `[string]` *(optional)* - message string before starting the action (see the next `action` key).\n    [Variable substitution](#variable-substitution) is possible.\n  - **action** `[string]` *(mandatory)* - name of the action, which is specified in the [actions](#actions-key) key in\n    the pipeline settings file (see [actions key](#actions-key)). Substitution of the value from the pipeline parameter\n    is allowed (see [Example 7](#example-7)). [Variable substitution](#variable-substitution) is possible.\n  - **after_message** `[line]` *(optional)* - the message string, which will be displayed after action completion\n    regardless of the execution result (see [Example 5](#example-5)). [Variable substitution](#variable-substitution) is\n    possible.\n  - **ignore_fail** `[boolean]` *(optional)* - a switch to ignore unsuccessful execution of the current action: if set,\n    the result of the current action will always be successful. Default is `false`.\n  - **stop_on_fail** `[boolean]` *(optional)* - a switch to stop pipeline execution when the action fails: if set, then\n    the entire pipeline will be completed immediately after the action fails. Default is `false`.\n  - **success_only** `[boolean]` *(optional, not compatible with the `fail_only` key)* - a switch to perform the current\n    action only if all previous actions were completed successfully, i.e. the action will be executed if the general\n    status of the current pipeline launch is not equal to 'FAILURE' (see [Example 6](#example-6)). Default is `false`.\n  - **fail_only** `[boolean]` *(optional, not compatible with the `success_only` key)* - flag to perform the current\n    action only if at least one of the previous actions was unsuccessful and the `ignore_fail` key was not set, i.e.\n    this is the opposite of `success_only` switch and the action will be performed if the overall status of the current\n    pipeline run is 'FAILURE'. Default is `false`.\n  - **dir** `[string]` *(optional)* - the name of the directory in which the action will be performed. If there is no\n    such directory, then it will be created inside the directory in which the pipeline started (for example, inside\n    `workspace` for Jenkins). It is allowed to specify any other full paths, for example: `/tmp` (see\n    [Example 6](#example-6)). [Variable substitution](#variable-substitution) is possible.\n  - **build_name** `[string]` *(optional)* - the name of the current build, which will be set before starting the\n    current action (see [Example 7](#example-7)). If the `success_only` or `fail_only` flags indicate skipping this\n    action, then the name of the current build (or current pipeline run) will not be changed.\n    [Variable substitution](#variable-substitution) is possible.\n  - **node** `[string or dictionary]` *(optional)* - key that determines the node change (for example, Jenkins or\n    Teamcity nodes). It can be specified as a string with the possibility of\n    [variable substitution](#variable-substitution) and then this value will be the name of the node, or otherwise it is\n    specified as a dictionary and can include the following keys:\n\n    - **name** `[string]` *(required, but not compatible with the `label` key)* - node name.\n      [Variable substitution](#variable-substitution) is possible.\n    - **label** `[string]` *(required, but not compatible with the `name` key)* - node tag (or *node label*).\n      [Variable substitution](#variable-substitution) is possible.\n    - **pattern** `[boolean]` *(optional)* - if the switch is enabled (`true`), then the search for node will be\n      performed by the string in the key `name`, or `label` and will be launched on the first one that matches search\n      pattern (see [Example 8](#example-8)). If the switch is disabled, the node will be selected only if there is a\n      complete match of the name (in the `name` key), or the node label (in the `label` key).\n\n    To launch an action on any free node, you should specify an empty key `node`, or `node: null` (see\n    [example 6](#example-6)).\n\n#### Example 5\n\n```yaml\n# A part of the configuration file setting up `stage_1` with customized messages.\n\nstages:\n  - name: stage_1\n    actions:\n      - before_message: Starting 'action_name_1'...\n        action: action_name_1\n        after_message: Just finished 'action_name_1' execution.\n      - before_message: Then starting 'action_name_2'...\n        action: action_name_2\n        fail_message: A custom message for 'action_name_2' that means it was failed.\n        success_message: |\n          A custom message for 'action_name_2' that means it was complete without errors.\n```\n\n#### Example 6\n\n```yaml\n# A part of a configuration file setting up the stage `stage_name` with parallel action run.\n# `action_name_2` will be launched on any free node, while the other actions will be launched\n# on the same node where it was originally pipeline was started. `action_name_3` will be executed\n# only if the previous two actions have been finished successfully. On executing `action_name_1`\n# inside the current folder where the pipeline started (for example, for Jenkins this folder\n# called `workspace`) the folder `temp` will be created, while the execution of `action_name_2`\n# will be executed in system temporary folder `/tmp`.\n\n  - name: stage_name\n    parallel: true\n    actions:\n      - action: action_name_1\n        dir: temp\n      - action: action_name_2\n        dir: /tmp\n        node:\n      - action: action_name_3\n        success_only: true\n```\n\n#### Example 7\n\n```yaml\n# A part of a configuration file with the pipeline parameter `PIPELINE_ACTION`,\n# which specifies the name of the action in `stage_name`. Before the action is executed,\n# the current build (or pipeline run) will be named as the `PIPELINE_ACTION` parameter\n# defined.\n\nparameters:\n  required:\n    - name: PIPELINE_ACTION\n      type: choice\n      description: Action to perform.\n      choices:\n        - action_one\n        - action_two\n\nstages:\n  - name: stage_name\n    actions:\n      - action: $PIPELINE_ACTION\n        build_name: $PIPELINE_ACTION\n```\n\n#### Example 8\n\n```yaml\n# A part of the configuration file setting up a `build_stage` with the choice of node\n# (displayed as a message to the console before the start of the action - `before_message`).\n\nstages:\n  - name: build_stage\n    actions:\n      - before_message: Starting build on 'build-x64-node-01.domain.com' jenkins node...\n        action: build_action\n        node: build-x64-node-01.domain.com\n      - before_message: \u003e-\n          Starting build on any jenkins node name starts with 'build-x64-node-'...\n        action: build_action\n        node:\n          name: build-x64-node-\n          pattern: true\n      - before_message: Starting build on any jenkins node with label 'build_nodes'...\n        action: build_action\n        node:\n          label: build_nodes\n      - before_message: Starting build on any jenkins node with label contains '_nodes'...\n        action: build_action\n        node:\n          label: _nodes\n```\n\n## 'actions' key\n\nThe key is a dictionary and defines named actions, where each nested key is the name of the action, and its values are\nthe action parameters:\n\n```yaml\nactions:\n  action_name_1:\n    action_parameter_1: value_1\n    action_parameter_2: value_2\n```\n\nThe action type is determined by the key parameters specified in it. The following types of actions are supported:\n\n- [**source cloning (git)**](#action-clone-sources-with-git),\n- [**install ansible collection from Ansible Galaxy**](#action-install-ansible-collection-from-ansible-galaxy),\n- [**run ansible playbook**](#action-run-ansible-playbook),\n- [**run script**](#action-run-script),\n- [**get artifact files**](#action-get-artifact-files),\n- [**get files from node (stash)**](#action-get-files-from-node-stash),\n- [**transfer files to node (unstash)**](#action-transfer-files-to-node-unstash),\n- [**run downstream pipeline**](#action-run-downstream-pipeline),\n- [**notifications send**](#action-notifications-send) ([email](#sending-notifications-via-email), or\n  [mattermost](#sending-notifications-via-mattermost)).\n\n[Variable substitution](#variable-substitution) is possible in any string values of the action parameters.\n\nIf any action was specified in the `actions` key, but wasn't specified in the `stages` key (or its action name wasn't\npassed during variable substitution), this action will be ignored. Also, if the `action` field in an action list\nelement in `stages` contains an empty value at the moment of checking the syntax and pipeline configuration parameters\n(for example, the variable will be specified later in one of the stage's scripts, so a link from `stages` to `actions`\nhas not been set yet - see [Example 18](#example-18)), then checking the syntax and parameters of this action won't be\nperformed.\n\n### Action: clone sources with git\n\n- **repo_url** `[string]` *(mandatory)* - link to the GitLab/GitHub repository.\n- **repo_branch** `[string]` *(optional)* - name of the branch in the repository. If the key is missing, then `main`\n  branch.\n- **credentials** `[string]` *(optional)* - CredentialsID for accessing the repository (see [Example 9](#example-9)).\nIf the key is missing, then the value is taken from the `GitCredentialsID` constant in the library\n[\"jenkins-shared-library\"](https://github.com/alexanderbazhenoff/jenkins-shared-library/blob/main/src/org/alx/commonFunctions.groovy).\n- **directory** `[string]` *(optional)* - directory inside the workspace for cloning. If the key is missing, project\ncloning will be done into the workspace.\n\n[Variable substitution](#variable-substitution) is possible in all keys of this action.\n\n#### Example 9\n\n```yaml\n# A part of the configuration file setting the action with defined CredentialsID to clone\n# sources from GitLab via ssh into the `subdirectory_name` folder located in the workspace,\n# and switching to the `develop` branch.\n\nactions:\n  git_clone_action_name:\n    repo_url: ssh://git@gitlab.com:username/project-name.git\n    repo_branch: develop\n    directory: subdirectory_name\n    credentials: a123b01c-456d-7890-ef01-2a34567890b1\n```\n\n### Action: install ansible collection from Ansible Galaxy\n\n- **collection** `[string, or list]` *(mandatory)* - namespace and name of the collection from\n  [Ansible Galaxy](https://galaxy.ansible.com/) for installation (see [Example 10](#example-10)), or a list of them.\n\nThe collection is always installing forcibly (using parameter `force`), which ensures their constant updating.\n[Variable substitution](#variable-substitution) is possible in all collection names.\n\n#### Example 10\n\n```yaml\n# An example of configuration file with an action installing one Ansible collection\n# `namespace.collection_name` and collections list.\n\nactions:\n  ansible_galaxy_install_action_name:\n    collections: namespace.collection_name\n  ansible_galaxy_install_list_action_name:\n    collections:\n      - namespace_1.collection_name_1\n      - namespace_2.collection_name_2\n```\n\n### Action: run ansible playbook\n\n- **playbook** `[string]` *(mandatory)* - playbook name (see [Example 11](#example-11) and [playbooks](#playbooks-key)\n  key). [Variable substitution](#variable-substitution) is possible.\n- **inventory** `[string]` *(optional)* - inventory name (see the [inventories](#inventories-key) key). If this key is\n  missing, then `default` ansible inventory inside the [inventories](#inventories-key) key is searched.\n\nAll environment variables (and pipeline parameters), as well as\n[Built-in pipeline variables](#built-in-pipeline-variables) will be available during playbook run. For example,\nto get the value of `universalPipelineWrapperBuiltIns.myCustomReport` inside a playbook, just specify its key as an\nenvironment variable: `$myCustomReport`.\n\n#### Example 11\n\n```yaml\n# A part of the configuration file with launching playbook as an action and\n# `ping_playbook_name` itself.\n\nactions:\n  ping_action_name:\n    playbook: ping_playbook_name\n\nplaybooks:\n  ping_playbook_name: |\n    - hosts: all\n      tasks:\n        - name: Ping\n          ansible.builtin.ping:\n```\n\n### Action: run script\n\n- **script** `[line]` *(mandatory)* - the name of the script to run it as a separate script ([Example 12](#example-12)),\n  or run as part of this pipeline (see the [scripts](#scripts-key) key).\n  [Variable substitution](#variable-substitution) is possible.\n\n#### Example 12\n\n```yaml\n# A part of the configuration file with running the script as an action\n# and the `bash_script_name` itself.\n\nactions:\n  run_script_action_name:\n    script: bash_script_name\n\nscripts:\n  bash_script_name:\n    script: |\n      #!/usr/bin/env bash\n      printf \"This is a %s script.\\n\" \"$(cut -d'/' -f4 \u003c\u003c\u003c\"$SHELL\")\"\n```\n\nIn a running script, same as a [playbooks](#action-run-ansible-playbook), environment variables and variables built into\nthe pipeline are also available. When [running a script \"as part of a pipeline\"](#scripts-key) it is also possible to\nchange key values of [built-in pipeline variables](#built-in-pipeline-variables) `universalPipelineWrapperBuiltIns`:\nall its changes will be inherited by other stages and actions of the pipeline. While changes to environment variables\ninside scripts will not be inherited by other stages and actions of the pipeline. To save values as a result of the\nscript, use built-in pipeline variables, or save the result to a file.\n\nAll scripts (except [of “as part of the pipeline”](#scripts-key)) are running through a shell call. To select the\nappropriate environment, you should specify an appropriate hashbang.\n\n### Action: get artifact files\n\n- **artifacts** `[string]` *(mandatory)* - path and name mask (or a comma-separated list of them) for\n  [archiving artifact files](https://www.jenkins.io/doc/pipeline/tour/tests-and-artifacts/).\n  [Variable substitution](#variable-substitution) is possible.\n- **excludes** `[string]` *(optional)* - path and name mask (or a comma-separated list of them) to exclude from\n  archiving (see [Example 13](#example-13)). [Variable substitution](#variable-substitution) is possible.\n- **allow_empty** `[boolean]` *(optional)* - flag that allows the absence of files that meet the conditions, specified\n  in `artifacts` and `excludes`. By default, `false`, that means that absence of files that satisfy conditions will\n  cause an error.\n- **fingerprint** `[boolean]` *(optional)* - a switch to include a\n  [checksum for artifact files](https://www.jenkins.io/doc/book/using/fingerprints/). Default is `false`.\n\n#### Example 13\n\n```yaml\n# A part of the configuration file setting up the action to get regression testing logs,\n# unit tests and general results (except unit test logs in JSON format). Missing files are\n# allowed, checksum calculation is disabled.\n\nactions:\n  archive_artifacts_action_name:\n    artifacts: regression_tests/**/logs/*, unit_tests/**/logs/*, results.txt\n    excludes: unit_tests/**/logs/*.json\n    allow_empty: true\n    fingerprint: false\n```\n\n### Action: get files from node (stash)\n\n- **stash** `[string]` *(mandatory)* - the name of the files set to get files from node (for example,\n[stash in Jenkins](https://www.jenkins.io/doc/pipeline/steps/workflow-basic-steps/#stash-stash-some-files-to-be-used-later-in-the-build)).\n  In fact, this is an identifier for a file set. [Variable substitution](#variable-substitution) is possible.\n- **includes** `[string]` *(optional)* - path and name mask (or a comma-separated list of them) for building files with\n  node. [Variable substitution](#variable-substitution) is possible.\n- **excludes** `[string]` *(optional)* - path and name mask (or a comma-separated list of them) to exclude files from\n  obtaining (see [Example 14](#example-14)). [Variable substitution](#variable-substitution) is possible.\n- **default_excludes** `[boolean]` *(optional)* - a switch to enable default exceptions (for example, for Jenkins, Ant\n  exceptions will have [the following list](https://ant.apache.org/manual/dirtasks.html#defaultexcludes)). Default is\n  `true`.\n- **allow_empty** `[boolean]` *(optional)* - a switch that allows the absence of files that meet the conditions,\n  specified in `artifacts` and `excludes`. The default is `false`, when the absence of files that satisfy the conditions\n  in `includes`, `excludes` and `default_excludes` will cause an error.\n\n### Action: transfer files to node (unstash)\n\n- **unstash** `[string]` *(required)* - name of a set of files for building files with node (for example,\n[stash in Jenkins](https://www.jenkins.io/doc/pipeline/steps/workflow-basic-steps/#stash-stash-some-files-to-be-used-later-in-the-build)).\n  In fact this is an identifier for a file set. [Variable substitution](#variable-substitution) is possible. To set the\n  path to transfer the files in, use [action key](#stages-key) `dir` (see [Example 14](#example-14)).\n\n#### Example 14\n\n```yaml\n# A part of the configuration file setting up the stage and actions of to move files\n# between nodes: all files except files in json format are copied from the logs folder in\n# the workspace on node 'my_node' to the 'my_folder' folder in the workspace on node\n# 'another_node'. The absence of files specified in the `includes` condition is allowed,\n# since `allow_empty` is set.\n\nstages:\n  - name: stash_unstash\n    actions:\n      - action: stash_files_from_node_action_name\n        node: my_node\n      - action: unstash_files_from_node_action_name\n        node: another_node\n        dir: my_unstash_folder\n\nactions:\n  stash_files_from_node_action_name:\n    stash: my_stash_name\n    includes: logs/*\n    excludes: logs/*.json\n    allow_empty: true\n  unstash_files_from_node_action_name:\n    unstash: my_stash_name\n```\n\n### Action: run downstream pipeline\n\nAn action that specifies a downstream pipeline run, or a job (hereinafter 'pipeline'), getting results and artifact\nfiles for the current pipeline run.\n\n- **pipeline** `[string]` *(mandatory)* - the name of downstream pipeline.\n  [Variable substitution](#variable-substitution) is possible.\n- **parameters** `[list]` - *(optional)* - list of parameters. If a downstream pipeline is parameterized, then each\n  element of the list is a parameter and has the following keys (see [Example 15](#example-15)):\n\n  - **name** `[string]` *(mandatory)* - downstream pipeline parameter name.\n  - **type** `[string]` *(mandatory)* - downstream pipeline parameter type: `string`, `text`, `password`, or `boolean`.\n  - **value** `[string or boolean]` *(mandatory)* - string or logical value, depending on a downstream parameter type.\n    [Variable substitution](#variable-substitution) is possible.\n\n- **propagate** `[boolean]` *(optional)* - pass completion status from the downstream pipeline: if set to `true`, or the\n  key is not specified, then failure of a downstream pipeline will bring an error in the upstream pipeline. However, if\n  `ignore_fail` is set for the current action in upstream pipeline, then the error will be transmitted, but the pipeline\n  will not end with an error and will continue execution - see [stages key](#stages-key)). If `propagate` is not set,\n  the completion status of the downstream pipeline will not be passed to the upstream (for Jenkins this is a\n  *'Propagate errors'* option). Default is `true`.\n- **wait** `[boolean]` *(optional)* - wait for the downstream pipeline to complete: if set, or not specified, then wait.\n  Otherwise, the upstream pipeline will not wait, and it will be impossible to receive completion status and artifact\n  files from the downstream pipeline. Actually in Jenkins it is 'Wait for completion' option. Default is `true`.\n- **copy_artifacts** `[dictionary]` *(optional)* - additional parameters for copying artifact files from a dowstream\n  pipeline (see [Example 15](#example-15) and [Copy Artifacts](https://plugins.jenkins.io/copyartifact/) plugin for\n  Jenkins):\n\n  - **filter** `[string]` *(mandatory)* - mask of paths and names (or a comma-separated list of them) to get artifact\n    files from a downstream pipeline. [Variable substitution](#variable-substitution) is possible.\n  - **excludes** `[string]` *(optional)* - a mask of paths and names (or a comma-separated list of them) to exclude\n    artifact files from the list. [Variable substitution](#variable-substitution) is possible.\n  - **target_directory** `[string]` *(optional)* - path inside the workspace to which artifact files will be copied.\n    If the key is not specified, then the artifact files will be copied to the workspace directly.\n    [Variable substitution](#variable-substitution) is possible.\n  - **optional** `[boolean]` *(optional)* - if `true`, then the upstream pipeline will not fail with an error if there\n    are no artifact files that match the conditions in the `filter` and `excludes` keys. Otherwise, if there are no\n    artifact files, the pipeline will fail with an error at the running the downstream pipeline action. However, if\n    `ignore_fail` is set in the stage definition, then the error will be passed to the upstream pipeline, but the\n    pipeline will not end with an error and will continue execution (see [stages key](#stages-key)). Default is `false`.\n  - **flatten** `[boolean]` *(optional)* - `true` to ignoring a directory structure of copied artifact files. If the key\n    is not specified, or `false`, then the entire directory structure will be preserved. Default is `false`.\n  - **fingerprint** `[boolean]` *(optional)* - a switch to enable\n    [checksum for artifact files](https://www.jenkins.io/doc/book/using/fingerprints/). Default is `false`.\n\n  Please note that\n  [Universal Wrapper Pipeline](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline) copies artifact\n  files from the downstream pipelines called by itself. There is no selection “by last successful”, “by last completed”\n  and/or by pipeline/job name.\n\n#### Example 15\n\n```yaml\n---\n\n# An example of a configuration file defining the only pipeline parameter\n# `UPSTREAM_PARAMETER`, the stage `run_downstream_pipeline_stage_name` and the\n# action to launch `downstream_pipeline_name` downstream pipeline, to which the\n# value of the upstream parameter `UPSTREAM_PARAMETER` is passed. If the execution\n# of the downstream pipeline `downstream_pipeline_name` fails, or during its execution\n# the logs folder is empty, then this will not cause errors.\n\nparameters:\n  required:\n    - name: UPSTREAM_PARAMETER\n      type: string\n      \nstages:\n  - name: run_downstream_pipeline_stage_name\n    actions:\n        action: run_jenkins_pipeline_action_name\n\nactions:\n  run_jenkins_pipeline_action_name:\n    pipeline: downstream_pipeline_name\n    parameters:\n      - name: UPSTREAM_PARAMETER\n        type: string\n        value: $UPSTREAM_PARAMETER\n    propagate: false\n    copy_artifacts:\n      filter: logs/*\n      fingerprint: true\n      target_directory: logs\n      optional: true\n```\n\n### Action: notifications send\n\n- **report** `[string]` *(required)* - method for sending notifications. [Variable substitution](#variable-substitution)\n  is possible. Supported:\n\n  - [**via email**](#sending-notifications-via-email) (see [Example 16](#example-16)) - value is set to `email`,\n  - [**via mattermost**](#sending-notifications-via-mattermost) (see [Example 17](#example-17)) - value is set to\n    `mattermost`.\n  - [**via telegram**](#sending-notifications-via-telegram) (see [Example 17](#example-17)) - value is set to `telegram`\n    (available in Universal Wrapper Pipeline starting from version 1.0.1).\n\nThe other keys parameters depend on the method of sending notifications.\n\n#### Sending notifications via email\n\nTo send email notifications in Jenkins, you will need [Email Extension](https://plugins.jenkins.io/email-ext/).\n\n- **to** `[string]` *(mandatory)* - recipient(s) addresses. [Variable substitution](#variable-substitution) is possible.\n- **reply_to** `[string]` *(optional)* - email address to respond to this notification.\n  [Variable substitution](#variable-substitution) is possible. Default for Jenkins is `'$DEFAULT_REPLYTO'`.\n- **subject** `[string]` *(optional)* - mail subject. [Variable substitution](#variable-substitution) is possible.\n- **body** `[string]` *(optional)* - mail text. [Variable substitution](#variable-substitution) is possible.\n\n#### Example 16\n\n```yaml\n---\n\n# An example of a configuration file specifying the only pipeline parameter `EMAIL`,\n# which set a list of recipients separated by a space (will be replaced by ', '),\n# the only stage and action of sending a notification via email. The mail text contains\n# built-in Jenkins variables: `env.JOB_NAME` (current pipeline build name),\n# `env.BUILD_URL` (URL to the current build), as well as the `multilineReport` (key of\n# `universalPipelineWrapperBuiltIns` variable) and `EMAIL` pipeline parameter.\n\nparameters:\n  required:\n    - name: EMAIL\n      type: string\n      description: Space separated email recipients list.\n      regex_replace:\n        regex: ' '\n        to: ', '\n      \nstages:\n  - name: email_report_stage_name\n    actions:\n        action: email_report_action_name\n\nactions:\n  email_report_action_name:\n    report: email\n    to: $EMAIL\n    subject: Test email report\n    body: |\n      Hi,\n      \n      I've just run a test for universal jenkins wrapper pipeline for '$JOB_NAME' pipeline,\n      finished with '$currentBuild_result' state. As you see sending report to $EMAIL done.\n      \n      Overall report is:\n      $multilineReport\n      \n      Check pipeline console for details: $BUILD_URL/console\n      This report was generated automatically, please do not reply.\n      \n      Sincerely,\n      Your Jenkins.\n```\n\n#### Sending notifications via Mattermost\n\n- **url** `[string]` *(mandatory)* - URL of Mattermost webhook, containing the channel key. For example:\n  `https://mattermost.com/hooks/\u003ctoken\u003e` (see [Example 17](#example-17)).\n  [Variable substitution](#variable-substitution) is possible.\n- **text** `[string]` *(mandatory)* - notification text. [Variable substitution](#variable-substitution) is possible.\n\n#### Sending notifications via Telegram\n\nThis functionality is available for Universal Wrapper Pipeline starting from version 1.0.1. Notifications are sent via\n[Telegram bot](https://core.telegram.org/bots/api#sendmessage).\n\n- **bot_token** `[string]` *(mandatory)* - token for [Telegram bot](https://core.telegram.org/bots/tutorial) (see\n  [Example 17](#example-17)). [Variable substitution](#variable-substitution) is possible.\n- **chat_id** `[string]` *(mandatory)* - unique identifier for the target chat or username of the target channel.\n  [Variable substitution](#variable-substitution) is possible.\n- **text** `[string]` *(mandatory)* - text of the message to be sent, 1–4096 characters after entities parsing.\n  [Variable substitution](#variable-substitution) is possible.\n- **message_thread_id** `[string]` *(optional)* - unique identifier for the target message thread (topic) of the forum;\n  for forum supergroups only. [Variable substitution](#variable-substitution) is possible.\n- **parse_mode** `[string]` *(optional)* - mode for parsing entities in the message text, e.g.: markdown, html (see\n  [\"Format options\"](https://core.telegram.org/bots/api#formatting-options) in official Telegram documentation).\n  [Variable substitution](#variable-substitution) is possible.\n- **link_preview_options** `[string]` *(optional)* - link preview generation options for the message (see\n  [\"Link preview options\"](https://core.telegram.org/bots/api#linkpreviewoptions) in official Telegram documentation).\n  [Variable substitution](#variable-substitution) is possible.\n- **disable_notification** `[boolean]` *(optional)* - sends the message silently. Users will receive a notification with\n  no sound. Default is `false`.\n- **protect_content** `[boolean]` *(optional)* - protects the contents of the sent message from forwarding and saving.\n  Default is `false`.\n- **api_url** `[string]` *(optional)* - Telegram Bot API URL. Used in cases where it is necessary to redirect http\n  requests (for example, through a http proxy). By default is `https://api.telegram.org/bot`, according to\n  [official Telegram documentation](https://core.telegram.org/bots/api). Specified by a global constant in\n  [Jenkins Shared Library](https://github.com/alexanderbazhenoff/jenkins-shared-library) (inside of `OrgAlxGlobals`\n  class).\n\n#### Example 17\n\n```yaml\n# A part of the configuration file with the tasks of sending a notifications to\n# Mattermost and Telegram. URL, tokens, and Chat ID are just for example.\n\nactions:\n  mattermost_report_action_name:\n    report: mattermost\n    url: https://mattermost.com/hooks/31895e09lg2m0g44dk4qeb847s\n    text: |\n      Hi, I've just run a test for universal jenkins wrapper pipeline: $JOB_NAME.\n      Overall report is:\n      ```\n      $multilineReport\n      ```\n      Please ignore this automatic report.\n\n  telegram_report_action_name:\n    report: telegram\n    bot_token: 4839574812:AAFD39kkdpWt3ywyRZergyOLMaJhac60qc\n    chat_id: '-213343255'\n    text: |\n      Hi, this is a silent Telegram message with\n      ```\n      markdown support.\n      ```\n      Forwarding and saving message options are disabled.\n    parse_mode: markdown\n    disable_notification: true\n    protect_content: true\n```\n\n## 'scripts' key\n\nThe key contains scripts, where each nested key is the name of that script, and its value is a dictionary with script\nparameters and script content. Scripts can also be executed “as part of a pipeline” (see [Example 18](#example-18)).\n\n- **pipeline** `[boolean]` *(optional)* - if this switch specified or set, then the script is executed 'as part of the\n  pipeline' (see [Example 18](#example-18)) and then you must also set the key, indicating in which CI tool (or\n  environment) this script should be executed: `jenkins`, `teamcity`, etc. If the key is not specified, or `false`, set\n  the code inside a `scripts` key that t will be executed 'separately from the pipeline' (although when launched it will\n  also inherit all environment variables) (see [Example 18](#example-12)). The difference is that in the first case you\n  can run code that native to the CI tool (Groovy for Jenkins, or Kotlin for Teamcity). In the second case you can run a\n  script in any language (perhaps you may need to install it on node) that will start as a subprocess from a pipeline.\n- **script** `[string]` *(required if not `pipeline: true`)* - script contents. Acceptable use hashbang (see\n  [Example 18](#example-12)).\n- **jenkins** `[string]` *(optional)* - code to execute only when run in Jenkins \"as part of the pipeline\". All pipeline\n  variables will be inherited (see [Built-in pipeline variables](#built-in-pipeline-variables)).\n- **teamcity** `[string]` *(optional)* - code to execute only when run in Teamcity \"as part of the pipeline\". All\n  pipeline variables will be inherited (see [Built-in pipeline variables](#built-in-pipeline-variables)).\n\n#### Example 18\n\n```yaml\n# A part of the configuration file with an action to run the code\n# 'as part of the pipeline' for Jenkins and Teamcity.\n\nactions:\n  run_part_of_pipeline_action_name:\n    script: script_name\n\nscripts:\n  script_name:\n      pipeline: true\n      jenkins: |\n        println String.format('EMAIL provided for %s action is awesome: %s',\n            env.PIPELINE_ACTION, env.EMAIL)\n      teamcity: |\n        println(String.format(\"EMAIL provided for %s action is awesome: %s\",\n            env.PIPELINE_ACTION, env.EMAIL))\n```\n\n## 'playbooks' key\n\nThe key contains ansible playbooks, where each nested key is the name of this script, and its values are the contents of\nthe playbook (see [Example 19](#example-19)). [Variable substitution](#variable-substitution) is possible.\n\n## 'inventories' key\n\nThe key contains an ansible inventory, where each nested key is the name of that inventory, and its value is the\ncontents of the inventory. [Variable substitution](#variable-substitution) is possible.\n\nFor all playbooks, at least one inventory with the name `default` must be specified in the configuration file, which\nwill be used for all playbooks (see [Example 19](#example-19)) in this configuration file. Each playbook can also have\nits own inventory: in this case, the inventory is created with the same name as the playbook to which it corresponds\n(see [Example 20](#example-20)). [Variable substitution](#variable-substitution) is possible.\n\n#### Example 19\n\n```yaml\n---\n\n# An example of a configuration file with pipeline parameters, stages, actions, playbook\n# and default inventory. All pipeline parameters specify hosts credentials for which\n# anisble ping will be performed. There is one single inventory named `default`, but in\n# this example the inventory could also have the name `run_ansible_playbook_action_name`.\n\nparameters:\n  required:\n    - name: IP_ADDRESSES\n      type: string\n      description: \u003e-\n        Space separated IP or DNS list of the host(s) to asnible ping: try to connect to host,\n        verify a usable python and return.\n      regex_replace:\n        regex: ' '\n        to: \"\\\\\\n\"\n    - name: SSH_LOGIN\n      type: string\n      description: SSH login for all specified hosts.\n    - name: SSH_PASSWORD\n      type: password\n      description: SSH password for all specified hosts.\n\nstages:\n  - name: stage_name\n    actions:\n      - action: run_ansible_playbook_action_name\n\nactions:\n  run_ansible_playbook_action_name:\n    playbook: playbook_name\n\nplaybooks:\n  playbook_name: |\n    - hosts: all\n      tasks:\n        - name: Perform ansible ping on the host(s)\n          ansible.builtin.ping:\n\ninventories:\n  default: |\n    [all]\n    $IP_ADDRESSES\n    [all:vars]\n    ansible_connection=ssh\n    ansible_become_user=root\n    ansible_ssh_common_args='-o StrictHostKeyChecking=no'\n    ansible_ssh_user=$SSH_LOGIN\n    ansible_ssh_pass=$SSH_PASSWORD\n```\n\n#### Example 20\n\n```yaml\n# A fragment of a configuration file with two playbooks\n# (`ansible_ping_playbook_name` and `install_curl_playbook_name`) and inventory for\n# each of them: when executing `ansible_ping_playbook_name`, authentication occurs\n# using a password, when executing `install_curl_playbook_name` using an ssh key.\n\nplaybooks:\n  ansible_ping_playbook_name: |\n    - hosts: all\n      tasks:\n        - name: Perform ansible ping on the host(s)\n          ansible.builtin.ping:\n  install_curl_playbook_name: |\n    - hosts: all\n      become: true\n      become_method: sudo\n      gather_facts: true\n      tasks:\n        - name: Install curl using ansible.builtin.package ansible module\n          ansible.builtin.package:\n          name: curl\n          state: present\n\ninventories:\n  ansible_ping_playbook_name: |\n    [all]\n    $IP_ADDRESSES\n    [all:vars]\n    ansible_connection=ssh\n    ansible_become_user=root\n    ansible_ssh_common_args='-o StrictHostKeyChecking=no'\n    ansible_ssh_user=$SSH_LOGIN\n    ansible_ssh_pass=$SSH_PASSWORD\n  install_curl_playbook_name: |\n    [all]\n    $IP_ADDRESSES\n\n    [all:vars]\n    ansible_connection=ssh\n    ansible_ssh_common_args='-o StrictHostKeyChecking=no'\n    ansible_user=$SSH_LOGIN\n    ansible_ssh_private_key_file=~/.ssh/id_rsa\n```\n\n# Built-in pipeline parameters\n\n- `SETTINGS_GIT_BRANCH` - branch from which pipeline settings will be loaded.\n- `NODE_NAME` - the name of the node on which the\n  [Universal Wrapper Pipeline](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline) will be\n  launched.\n- `NODE_TAG` - node tag (or *node label*).\n  [Universal Wrapper Pipeline](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline) starts on the\n  node to which this tag is assigned.\n- `UPDATE_PARAMETERS` - if enabled, then update the pipeline parameters from the configuration file without performing\n  stages and actions. Can be used if the pipeline parameters are changed in the configuration file, but anything except\n  the name (type, default values, description, or handling).\n- `DRY_RUN` - if enabled, no actions and changes will be performed, but service messages will be displayed in the\n  console as if the 'dry run' had not been enabled.\n- `DEBUG_MODE` - режим отладки для детализированного логирования в консоль.\n\nAll [pipeline-built-in parameters](#built-in-pipeline-parameters) are available for use in playbooks, inventory, scripts\nand pipelines by the same way as in any other pipelines: for example, the \"DRY_RUN\" parameter in Jenkins will be\navailable through the environment variable `DRY_RUN` and the Groovy variables `env.DRY_RUN` and `params_DRY_RUN`.\n\n# Built-in pipeline variables\n\nThe built-in `universalPipelineWrapperBuiltIns` variable *[dictionary, or Map]* contains keys that can be used in the\nconfiguration file (for example, when generating reports):\n\n- `universalPipelineWrapperBuiltIns.multilineReportMap` *[dictionary, or Map]* - contains a dictionary of statuses and\n  information about each action in the pipeline stages. The key is intended to be used in code \"as part of a pipeline\".\n  The structure of the Map is identical to the description of the `addPipelineStepsAndUrls()` function in\n  [jenkins-shared-library](https://github.com/alexanderbazhenoff/jenkins-shared-library) in the function and looks like:\n\n  ```groovy\n  universalPipelineWrapperBuiltIns.multilineReport = [\n          'stage_1[0]': [\n              name : 'stage_1 [0]',\n              state: true|false,\n              url  : 'Information about 1st action in stage_1.'\n          ],\n          'stage_1[1]': [\n              name : 'stage_1 [1]',\n              state: true|false,\n              url  : 'Information about 2nd action in stage_1.'\n          ],\n          'stage_2[0]': [\n              name : 'stage_2 [0]',\n              state: true|false,\n              url  : 'Information about 1st action in stage_2.'\n          ]\n  ]\n  ```\n\n- `universalPipelineWrapperBuiltIns.multilineReportMapStages` *[dictionary, or Map]* - contains only a dictionary of\n  stage states. The structure is similar to *multilineReportMap*:\n\n  ```groovy\n  universalPipelineWrapperBuiltIns.multilineReportMapStages = [\n          'stage_1': [\n              name : 'stage_1',\n              state: true|false,\n              url  : '6 actions.'\n          ],\n          'stage_2': [\n              name : 'stage_2',\n              state: true|false,\n              url  : '4 actions in parallel.'\n          ]\n  ]\n  ```\n\n- `universalPipelineWrapperBuiltIns.multilineReport` *[string]* - contains a text table of statuses and information\n  about each action and stage of the pipeline. The content is identical to *multilineReportMap*, but more printable.\n  This key does not contain color codes (ASCII colors), that is more convenient for inserting when generating various\n  [notifications](#action-notifications-send).\n- `universalPipelineWrapperBuiltIns.multilineReportStages` *[string]* - contains only a text table of stage states. No\n  color codes included, because of intended for generating the text of various\n  [notifications](#action-notifications-send). The overall stage execution status will be updated only after all actions\n  in the stage have been completed.\n- `universalPipelineWrapperBuiltIns.multilineReportFailed` *[string]* - contains a text table of only failed actions in\n  stages. Contains an empty string when all actions are completed successfully. No color codes included, because of\n  intended for generating the text of various [notifications](#action-notifications-send).\n- `universalPipelineWrapperBuiltIns.currentBuild_result` *[string]* - contains overall execution state of the current\n  pipeline run: `SUCCESS`, or `FAILED` (for example, for Jenkins its contents are identical to `currentBuild.result`).\n- `universalPipelineWrapperBuiltIns.multilineReportStagesFailed` *[string]* - contains a text table of only failed\n  stages. Contains an empty string when all stages are completed successfully. No color codes, because of intended for\n  generating the text of various [notifications](#action-notifications-send). The overall stage execution updates\n  only after all actions in the stage have been completed.\n- `universalPipelineWrapperBuiltIns.currentBuild_result` *[string]* - contains an overall execution state of the current\n  pipeline run: `SUCCESS`, or `FAILED` (for example, for Jenkins this value is identical to `currentBuild.result`).\n- `universalPipelineWrapperBuiltIns.ansibleCurrentInstallationName` *[string]* (deprecated) - contains the name of the\n  ansible installation (for example, in Jenkins its value is set in the\n  [Global Configuration Tool](https://issues.jenkins.io/browse/JENKINS-67209). Not used and will probably be removed\n  soon as recent changes in [jenkins shared library](https://github.com/alexanderbazhenoff/jenkins-shared-library) runs\n  ansible playbooks through a shell call by default.\n\nWhen running scripts ['as part of a pipeline'](#scripts-key), it is also allowed to\n[create your own keys](#using-variables-in-scripts-and-playbooks) for the `universalPipelineWrapperBuiltIns` variable.\nFor example:\n\n```groovy\nuniversalPipelineWrapperBuiltIns.myCustomReport = 'Some text of my custom report'\n```\n\nUpon completion of the current script call \"as part of a pipeline\", these keys will be updated for the entire pipeline.\nBuilt-in pipeline variable keys are not accessible when running scripts ['as part of the pipeline'](#scripts-key), but\nthey are accessible in environment variables of the same name (see\n[Using variables in scripts and playbooks](#using-variables-in-scripts-and-playbooks) and [Example 23](#example-23)):\n\n```groovy\n// The value of universalPipelineWrapperBuiltIns.multilineReport can be output as:\nprintln env.multilineReport\n```\n\n# Variable substitution\n\nIn the configuration file, most string key values can use any pipeline parameter or environment variable (if\nsubstitution is possible, this is indicated in the key description above). It is allowed to use several variables\ncombined with plain text (see [Example 21](#example-21)). [Built-in pipeline variables](#built-in-pipeline-variables)\nsubstitution is also possible inside the action description (see [Example 22](#example-22)): for example, for variable\nsubstitution of `universalPipelineWrapperBuiltIns.multilineReport` key value, you can just mention the same key name,\nlike the same way you use environment variable - `$multilineReport` (see [Example 18](#example-18)).\n\n#### Example 21\n\n```yaml\n---\n\n# A part of the configuration file with substitution of pipeline parameters\n# in the `before_message` and `action` keys.\n\nparameters:\n  required:\n    - name: FOO\n      type: string\n    - name: BAR\n      type: string\n    - name: BAZ\n      type: string\n\nstages:\n  - name: own stage\n    actions:\n      - before_message: |\n          Starting the action combined from FOO='$FOO', BAR='$BAR' and BAZ='$BAZ' values.\n        action: $FOO$BAR$BAZ\n```\n\n#### Example 22\n\n```yaml\n---\n\n# An example of a configuration file for launching an ansible playbook or pipeline\n# (selected by the `ACTION` parameter). The name of the playbook or pipeline is\n# specified by the `ACTION_SUBJECT` parameter. The username `USERNAME` is also\n# passed to the playbook or pipeline.\n\nparameters:\n  required:\n    - name: USERNAME\n      type: string\n      default: 'jenkins'\n      description: \u003e-\n        Run action under specified username (use in ansible inventory for login\n        or pass to downstream pipeline).\n    - name: ACTION\n      type: choice\n      choices:\n        - run playbook\n        - run pipeline\n      description: Choose an action to perform.\n    - name: ACTION_SUBJECT\n      type: string\n      # The default value is set equal to an existing ansible playbook name or a pipeline.\n      default: subject_name\n      description: Specify an ansible playbook or downstream pipeline name here.\n\nstages:\n  # The pipeline `ACTION` parameter will be substituted into the stage name and the first\n  # action. The `USERNAME` parameter will also be inserted into the message before the\n  # action.\n  - name: $ACTION report\n    actions:\n      - before_message: Ready to $ACTION under $USERNAME\n        action: $ACTION\n      - action: email report\n\nactions:\n  run playbook:\n    playbook: $ACTION_SUBJECT\n  run pipeline:\n    pipeline: $ACTION_SUBJECT\n    parameters:\n      - name: USERNAME\n        type: string\n        value: $USERNAME\n  email report:\n    report: email\n    to: '$DEFAULT_REPLYTO'\n    subject: Test email report\n    # The message will be filled with both environment variables (`JOB_NAME`, `EMAIL`\n    # and `BUILD_URL`) and variables built into the pipeline (`currentBuild_result`\n    # and `multilineReport`). Note that for built-in variables, you do not need to\n    # specify the full name `universalPipelineWrapperBuiltIns` as the value of the\n    # `body` key.\n    body: |\n      Hi,\n\n      I've just run a test for universal jenkins wrapper pipeline for\n      '$JOB_NAME' pipeline, finished with '$currentBuild_result' state.\n      As you see sending report to $EMAIL done.\n\n      Overall report is:\n      $multilineReport\n\n      Check pipeline console for details: $BUILD_URL/console\n      This report was generated automatically, please do not reply.\n\n      Sincerely,\n      Your CI.\n        \nplaybooks:\n  subject_name: |\n    - hosts: all\n      tasks:\n        - name: \"Perform ansible ping on the host(s)\"\n          ansible.builtin.ping:\n\ninventories:\n  default: |\n    [all]\n    192.168.0.200\n    192.168.0.201\n    [all:vars]\n    ansible_connection=ssh\n    ansible_become_user=root\n    ansible_ssh_common_args='-o StrictHostKeyChecking=no'\n    ansible_ssh_user=$USERNAME\n    ansible_ssh_pass=my_password\n    ansible_become_pass=my_password\n```\n\n# Using variables in scripts and playbooks\n\nAll environment variables are available for use, both during script execution and when running code\n['as part of a pipeline'](#scripts-key). Environment variables are the same for parallel action launches and the entire\npipeline. The keys of the [built-in pipeline variable](#built-in-pipeline-variables) `universalPipelineWrapperBuiltIns`\nare also available in environment variables, but in the built-in variable the keys of the same name will be created only\nupon completion of the script (see [Example 23](#example-23)). Please avoid creating existing\n`universalPipelineWrapperBuiltIns` variable keys when naming variables inside shell scripts, pipeline parameters, or\nwhen creating new keys (you can use the `env` shell command, or `println env` in Jenkins and Groovy for quick\nreference).\n\n#### Example 23\n\n#### Пример 23\n\n```yaml\n# A part of the configuration file with actions and scripts defining:\n# - bash script for setting the environment variable and displaying it;\n# - display this environment variable and create a key `myKey` for the\n#   variable `universalPipelineWrapperBuiltIns` in running 'as part of\n#   pipeline' Jenkins script;\n# - a script to display key value as an environment variable, launched\n#   'as part of the pipeline';\n# - bash script to display the value of this key.\n\nactions:\n  setup_env_variable:\n    script: script_1\n  show_variable_and_setup_keys:\n    script: script_2\n  show_updated_key_as_env_variable_in_groovy:\n    script: script_3\n  show_updated_key_as_env_variable_in_bash:\n    script: script_4\n\nscripts:\n  script_1:\n    script: |\n      #!/usr/bin/env bash\n      MY_ENV_VARIABLE='my env variable text'\n      printf \"MY_ENV_VARIABLE was defined. Now it's '%s'.\\n\" \\\n        \"$MY_ENV_VARIABLE\"\n  script_2:\n    pipeline: true\n    # Please note that declaring the universalPipelineWrapperBuiltIns variable\n    # inside the script, as well as return, is not required to return it. Any\n    # type of key at the end of the script “as part of the pipeline” will be\n    # converted to the string value of the environment variable of the same name.\n    jenkins: |\n      println String.format('Print my MY_ENV_VARIABLE env variable: %s',\n          env.MY_ENV_VARIABLE)\n      universalPipelineWrapperBuiltIns.myKey = 'my key text'\n      println String.format('Print myKey: %s',\n          universalPipelineWrapperBuiltIns.myKey)\n  script_3:\n    pipeline: true\n    jenkins: |\n      println String.format('%s as environment variable only: %s',\n          'Now myKey is available in groovy code', env.myKey)\n  script_4:\n    script: |\n      #!/usr/bin/env bash\n      printf \"Print myKey in bash: '%s'.\\n\" \"$myKey\"\n```\n\n#### Example 24\n\nTo use pipeline parameters or environment variables, you may need to format the values of these parameters or variables.\nLet's say the pipeline parameter `FOO` contains some dictionary (dict) like:\n\n```yaml\nkey1: value1\nkey2: value2\n```\n\nThen it needs to be passed in an ansible playbook variable as a dictionary. And the pipeline parameter `BAR` contains a\nspace-separated list (list) of the form `one two three` and it must be passed in the ansible playbook variable as a\nlist. The transfer of environment variables (or pipeline parameters) inside the playbook will take the following form:\n\n```yaml\n# An example of setting the variables FOO (dict) and BAR (list) in ansible playbook\n# inside the configuration file.\n\nplaybooks:\n  playbook_name: |\n      - hosts: all\n        become: true\n        become_method: sudo\n        gather_facts: true\n\n        tasks:\n\n          - name: \"Set ansible_variable_foo=FOO as dict, ansible_variable_bar=BAR as list\"\n            ansible.builtin.set_fact:\n              ansible_variable_foo: \"{{ lookup('ansible.builtin.env', 'FOO') | from_yaml }}\"\n              ansible_variable_bar: \"{{ '$BAR'.split(' ') | trim }}\"\n\n# Note that setting up variables whose values are multiline directly by inserting them\n# inside a playbook 'ansible_variable_foo: $FOO' will break yaml formatting in a playbook.\n```\n\n# Configuration file examples\n\n- [`example-pipeline.yaml`](settings/example-pipeline.yaml): an abstract but working example with the maximum set of\n  supported options and usage comments. Some actions end with an error, but this is normal for demonstrating their\n  handling and console logging.\n- [`downstream-example-pipeline.yaml`](settings/downstream-example-pipeline.yaml): an abstract but working example of\n  how to configure the launch of downstream pipelines and work with artifact files.\n- [`install-postgresql.yaml`](settings/install-postgresql.yaml) - example wrapper for installing PostgreSQL for Linux\n  using the ansible role\n  [postgresql](https://github.com/alexanderbazhenoff/ansible-collection-linux/tree/main/roles/postgresql).\n\n\u003c!-- docs-ci-cut-begin --\u003e\n# URLs\n\n- [**jenkins Universal Wrapper Pipeline**](https://github.com/alexanderbazhenoff/jenkins-universal-wrapper-pipeline)\n  source code.\n\n\u003c!-- docs-ci-cut-end --\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falexanderbazhenoff%2Funiversal-wrapper-pipeline-settings","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falexanderbazhenoff%2Funiversal-wrapper-pipeline-settings","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falexanderbazhenoff%2Funiversal-wrapper-pipeline-settings/lists"}