UAC Utility: Jobs As Code (JaC)
Disclaimer
Your use of this download is governed by Stonebranch’s Terms of Use, which are available at Stonebranch Integration Hub - Terms of Use.
Overview
Jobs-as-code is an approach to automating software delivery pipelines in which the job configuration is managed as code. This approach allows developers to manage job configurations like their application code complete with version control, testing, and continuous integration.
Whether you create your Universal Automation Center (UAC) job definitions using the drag-and-drop designer or as code in a development environment, the UAC jobs-as-code solution provides guidance and tools to integrate those definitions with a Git repository.
Version Information
Template Name | Extension Name | Version | Status |
|---|---|---|---|
Jobs As Code | ue-jobs-as-code | 2 (Current 2.3.0) | Fixes and new features are introduced. Compatibility starts from UAC/UAG 7.6.0.0 onwards. |
| Jobs As Code | ue-jobs-as-code | 1 | Hot Fixes Only (Until UAC 7.3's End of Support). |
Refer to Changelog for version history information.
Version 2.3.0 introduces new features compatible only with Universal Controller and Universal Agent of version 7.6 onwards. Therefore, version 2.3.0 should not be installed if your Universal Controller & Agent are of version less than 7.6.
Customers are encouraged to upgrade their Universal Agents to 7.6 to benefit from features introduced in version 2.3.0.
Software Requirements
This integration requires a Universal Agent and a Python runtime to execute the Universal Task.
Area | Description |
|---|---|
Python Version | Requires Python Version 3.11. Tested with Agent bundled python distribution |
Universal Agent | Both Windows and Linux agents are supported:
|
Universal Controller | Universal Controller Version >= 7.6.0.0 |
Network and Connectivity | This integration needs outbound HTTPS connectivity with GitLab, GitHub, Bitbucket Cloud, or Azure DevOps. It also needs outbound SSH connectivity (depending on the Git protocol used) for exporting and importing UAC Definitions, in addition to HTTPS outbound connectivity to the Universal Controller for retrieving the UAC Definitions and importing them from Git. |
GitLab | Supported editions:
|
GitHub | Supported plans:
|
Bit Bucket | Support plans:
|
Azure DevOps | Supported plans:
|
Key Features
| Feature | Description |
|---|---|
| List UAC Definitions | Query UAC definitions prior to running an actual export to Git, to validate the selection criteria, without any write operations in the target repository. This feature should provide a list of UC definitions that can then be exported to a Git repository. |
| Export to Git Repository | Export selected UAC Definitions to the selected Git Repository. By using this feature, the UAC user will be able to export the selected UAC Definitions to an external Git repository. After the export, this repository can be used as a backup or as a basis for developer collaboration on top of a source version control system. |
| Import from Git Repository | Import selected UAC Definitions. stored already in Git, back to the selected Universal Controller. This feature provides the opportunity for restoration of the UC server (recovery scenarios) or for updating UAC Definitions. For UC version 7.3, or higher, the import feature can be triggered by using webhooks. |
Feature: Import Mode
The Import Mode input field introduced in version 2.2.0 is available for the "Import from Git Repository" Action. The field covers the following scenarios.
- "Generic Webhook and Custom" Mode - This mode provides import of UC definitions manually using lists for Add, Modify, or Remove definitions on the Controller, or using Webhook Payloads. For manual imports, operations are processed in the following order: Add operations first, then Modify operations, and finally Remove operations.
- "Insert or Update" Mode - This mode provides import of UC definitions manually using a single Modify list for both adding and modifying definitions on the Controller. Each definition specified in the list is separately processed and, based on the presence on the Controller, it is either added or modified. For this mode, there is no specific order requirement. Both add and modify definitions can be included in the list, as the handling is done internally.
In case of dependencies between the entities to be imported, these relationships are automatically detected. Entities are then processed in the correct order. For creation/modification, dependencies are resolved first. For deletion, the order is reversed to prevent conflicts.
Feature Flags
There are cases where some functionalities could become deprecated, and new features are introduced in a stepwise approach to inform customers early enough to take the necessary steps given potential future breaking changes. The activation/deactivation of those features is controlled by Feature Flags. Not all features are entering this lifecycle approach, but when this is applicable, related feature flags are documented. The Feature State Transition diagram and related information is presented below:
The following features are subject to this lifecycle approach
Feature Description | Feature State History | Information |
|---|---|---|
Disable the default commit message prefix. |
| This is a stable feature. To enable the feature, set environment variable UE_FF_DISABLE_DEFAULT_COMMIT_PREFIX=True. Setting any other value or not setting this environment variable means that the feature is not activated. |
Supported Actions
Action: List UAC Definitions
Query UAC definitions prior to running an actual export to Git, to validate the selection criteria, without any write operations in the target repository. This feature should provide a list of UC
definitions that can later be exported to a Git repository.
Configuration examples
User Scenario: Query all UAC Definitions that are stored in UAC, except Scripts and Custom Days, without a proxy connection.
User Scenario: Query all UAC Definitions that are part of a workflow with the name 'test-workflow', with a proxy connection.
Action Output
Output Type | Description | Example |
|---|---|---|
EXTENSION | Standard Universal Extension format The extension output follows the standard Extension output format, providing:
| |
STDOUT | All definitions matched the selection criteria, in table format. |
Action: Export to Git Repository
Export selected UAC Definitions to the selected Git Repository. By using this feature, the UAC user can export the selected UAC Definitions to an external Git repository. After the export, this repository can be used as a backup or as a basis for developer collaboration on top of a source control versioning system.
Configuration examples
User Scenario: Export UAC Definitions to Gitlab using "HTTP(S)" Git Protocol, contained in the Bundle named uc_bundle, except for Email and Peoplesoft Connections. The selected definitions will be stored under the "/export" folder under the "export/7.3" branch in .yaml format.
User Scenario: Export UAC Definitions to Azure DevOps using "HTTP(S)" Git Protocol. Organization and repository names must be included in the Git Service Provider URL.
User Scenario: Export UAC Definitions to GitHub using "SSH" Git Protocol, contained in the Bundle named uc_bundle. Sign the commit with the exported definition using a private key. Use the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL for setting up the author and committer of the commit. These values can point to the same user, or different users can be the author and committer.
Action Output
Output Type | Description | Example |
|---|---|---|
EXTENSION | The extension output follows the standard Extension output format, providing:
| |
STDOUT | All definitions matched the selection criteria, in table format. |
Action: Import from Git Repository
Import selected UAC Definitions. already stored in Git, back to the selected Universal Controller. This feature provides the opportunity for restoration of the Universal Controller server (recovery scenarios) or for updating UAC Definitions.
Import UC definitions manually
User Scenario: Import the specified files using Git Protocol "HTTP(S)", stored in the corresponding paths of Add, Modify, and Remove Definitions Lists from GitHub to UAC. Files in the Add list will be added to UAC, files in the Modify list will modify existing definitions, and files in the Remove list will be deleted from UAC.
User Scenario: Import from GitHub, using Git Protocol "HTTP(S)", all the files that are stored in the "export/7.3" branch and modify the existing corresponding UAC Definitions.
User Scenario: Import from Azure DevOps, using Git Protocol "SSH", the file specified in Modify list, stored in "test-branch".
Import UC definitions automatically via Webhooks
Starting from UAC 7.3 and utilizing Global Universal Events, this integration can be configured to get triggered automatically when a change is made in a Git repository.
With the proper configuration, Universal Events can invoke a Jobs As Code Task, which will parse the Git webhook payload, define the added/modified/removed file lists, and trigger an import execution.
Process Flow
The following image demonstrates the flow of events that occur as soon as a GitLab/GitHub/Bitbucket Webhook is triggered.
Import from Git Repository using Git Webhooks and Global Universal Events
Configuration
The following steps are a guide to setting up UAC and the integrated Git provider’s Webhook to automatically trigger Jobs As Code Tasks.
Create a new Global Event Template that shall receive the Git provider’s Webhook payload. Set option "Unmapped Attributes Policy" to "Include Attributes".
Create a Universal Monitor and link it with the Global Event Template created in Step 1.
Create a Universal Monitor Trigger assigning to it
the Universal Monitor created in Step 2
a Jobs as Code Task that should be triggered when a new Git Webhook is invoked. The integration task should be configured to utilize the event’s webhook payload (see sections Parse GitLab/GitHub Webhook Payload, Parse Bit Bucket and Azure DevOps Webhook Payload, stored in UAC built-in variable
${ops_trigger_<universal_monitor_name>_payload}.
Set up a repository Webhook in the integrated GitLab/GitHub/BitBucket platform and select the "Push" trigger option. Link the Webhook to the Universal Controller Event created in Step 1 as follows:
If the controller URL is https://somehost.yourdomain.com/uc/, the Webhook’s target URL should be https://<uc_user>:<us_password>@somehost.yourdomain.com/uc/resources/universalevent/push/<name of the event>.
A Webhook can also be configured with a secret token for enhanced security. More information about this feature can be found for GitHub and GitLab providers.11.
Avoidance of Cyclic Imports
When an “Export to Git Repository” action is performed through a Universal Task, it triggers a push event towards the configured Git Service Provider. This push event leads to the triggering of the Git Service Provider Webhook. If configured as above, this webhook should create a Universal Event to UAC, for further processing to trigger an “Import from Git Repository” action. To prevent this cyclic behavior, a configuration is required to filter out those unnecessary imports. This can be accomplished if the Universal Monitor that listens for Webhook Events triggers a workflow configured appropriately to filter such cyclic requests.
The best practice suggested to filter out those cyclic imports is to ignore the imports initiated by UAC by configuring a dedicated Git user for the “Export” related tasks. The triggered workflow can start with a task that evaluates ${ops_trigger_<universal_monitor_name>_payload} to check if the request is initiated by the UAC git User. If yes, the request can be ignored. If no, the “Import from Git Repository” task can be executed.
The following image demonstrates the example above
Filter out webhooks that were triggered from the "Export to git Repository" Action.
Parse GitLab/GitHub Webhook Payload
In the 'Actions' section of the task, three variables need to be set, one for each import list. The name of the variable should also be put in the corresponding field of the template. The value of the variable should be a UC function that uses a JSON path to extract the added, modified, and removed files from the Git Webhook payload. Parse UAC variable holding the webhook payload, using UAC built-in JSON Path function: ${_varJsonPath('ops_trigger_<universal_monitor_task_name>_payload','$.commits[*].added[*]','',',')}
The Universal Task that will be triggered by the webhook should have the name of the Action Variables inside Add, Modify, and Remove UC Definitions Lists, with the prefix "var:", enclosed in a list, as demonstrated in the example below:
Task variables can also be used with the normal Controller syntax, for instance:
${added_definitions}. However, it is strongly suggested to use the custom [var: <variable name>], in order to avoid reaching size limits due to variable resolution on the fly.In this scenario, any input in the Webhook Payload field will be ignored.
Parse Bit Bucket and Azure DevOps Webhook Payload
Import from Bitbucket via Webhook
In this scenario, any input in Add/Modify/Remove UC Definition List fields will be ignored.
Import UC definitions: "Insert or Update" Mode
User Scenario: Import from GitHub all the files that match a regular expression pattern stored in the "export/7.3" branch, and add or modify the existing corresponding UAC Definitions.
Action Output
Output Type | Description | Example |
|---|---|---|
EXTENSION | The extension output provides the following information:
| |
STDOUT | All definitions matched the selection criteria, in table format. |
Input Fields
The input fields for this Universal Extension are described below.
Field | Type | Description | Version Information |
|---|---|---|---|
Action | Choice | Action performed upon the task execution. Available actions are as follows.
| Introduced in 1.0.0 |
Universal Controller URL | Text | The Universal Controller URL will be used to query and import UC Definitions. | Introduced in 1.0.0 |
Universal Controller Credentials | Credentials | Universal Controller credentials that provide access to the Universal Controller Web Services. The user should be configured with "Web Service Access=True". | Introduced in 1.0.0 |
UC SSL Certificate Verification | Checkbox | Enables/Disables certificate verification against Universal Controller URL. For example, if self-signed certificates are used to connect with UAC. Default setting is checked. | Introduced in 1.0.0 |
Selection Method | Checkbox | Select or filter specific UC Definitions for listing or exporting to Git repository.
Visible only when the selected Action is "List UAC Definitions" or "Export to Git Repository". If using a "Definition Name" Selection Method, the "Definition Name (Wildcard)" achieves better performance than "Definition Name (Regex)". | Introduced in 1.0.0 |
Selection Name | Dynamic Choice | The corresponding filter value for the Selection Method field. When the Selection Method is "Definition Name (Regex)" or "Definition Name (Wildcard)", the value provided in the field works as a filter applied on the UC Definition name. The value should be a regex or a text with wildcard (depending on the selection method)
Visible only when the selected Action is "List UAC Definitions" or "Export to Git Repository". | Introduced in 1.0.0 |
Selection Exclude List | Choice | Exclude various UC Definition types of resources from the selection. Visible only when the selected Action is "List UAC Definitions" or "Export to Git Repository". | Introduced in 1.0.0 |
Git SSL Certificate Verification | Checkbox | Enables/Disables certificate verification against Git Service Provider URL. Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository". Default setting is checked. | Introduced in 1.0.0 |
| Git Protocol | Choice | The protocol used when accessing a Git repository. The available options are as follows.
| Introduced in 2.3.0 |
Git Service Provider | Choice | The Git service provider the task is using.
Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository", and when Git Protocol is "HTTP(S)". | Introduced in 1.0.0 |
Git Service Provider URL | Text | The Git service provider URL the task is using. Examples for each Git Provider Version:
Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository". | Introduced in 1.0.0 |
Git Credentials | Credentials | The credentials that should be used to access the Git repository. The Credentials definition should be as follows.
Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository". | Introduced in 1.0.0 |
Git Repository | Dynamic Choice | The repository the task will use to import or export UAC Definitions. The list of values is retrieved from the Git Service Provider. Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository", and when Git Protocol is "HTTP(S)". | Introduced in 1.0.0 |
| Git Repository | Text | The repository the task will use to import or export UAC Definitions. Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository", and when Git Protocol is "SSH". | Introduced in 2.3.0 |
Git Repository Branch | Dynamic Choice | The repository branch that the task will use to import or export UAC Definitions. The list of values is retrieved from the Git Service Provider. Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository". | Introduced in 1.0.0 |
Git Repository Path | Text |
Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository". | Introduced in 1.0.0 |
Git Repository File Format | Choice | The file format is used to read and write in the Git repository. The available options are as follows.
Visible only when the selected Action is "Import from Git Repository" or "Export to Git Repository". | Introduced in 1.0.0 |
Git Commit Message | Text | The optional git commit message for the commits that will take place during export. The commit message For example, if the commit message is "test export" the To adjust the default prefix, use the Feature Flag UE_FF_DISABLE_DEFAULT_COMMIT_PREFIX. Visible only when the selected Action is "Export to Git Repository". | Introduced in 1.0.0 |
| Import Mode | Choice | The mode in which the UC definitions will be imported. The following options are available.
Visible only when the selected Action is "Import from Git Repository". The "Generic Webhook and Custom Mode (default)" Import Mode covers the existing functionality of the Import action that existed on version 2.1.1. | Introduced in 2.2.0 |
| Use Regular Expression | Checkbox | Enables/Disables using regular expression patterns for filtering the Git file paths that should be used to create or modify UC Definitions. Visible only when the selected Import Mode is "Insert or Update Mode". Default setting is checked. | Introduced in 2.2.0 |
Add UC Definitions List | Text | The comma-separated list of Git file paths that should be used to create UC Definitions. Type "*" to select all files from Git provider and add them to UAC. UC Variables are accepted as input. Visible only when the selected Import Mode is "Generic Webhook and Custom Mode". | Introduced in 1.0.0 |
Modify UC Definitions List | Text | The comma-separated list of Git file paths that should be used to modify UC Definitions. Type "*" to select all files from Git provider and modify the corresponding definitions of UAC. UC Variables are accepted as input. Visible only when the selected Import Mode is "Generic Webhook and Custom Mode" or "Insert or Update Mode". When the Import Mode is "Generic Webhook and Custom Mode", the value provided in the field is used to modify UC Definitions. When the Import Mode is "Insert or Update Mode", the value provided in the field is used to create and/or modify UC Definitions. | Introduced in 1.0.0 |
Remove UC Definitions List | Text | The comma-separated list of Git file paths that should be used to remove UC Definitions. Type "*" to select all files from Git provider and Visible only when the selected Import Mode is "Generic Webhook and Custom Mode". | Introduced in 1.0.0 |
Proxy Type | Choice | What type of proxy is in use (if any). The available options are as follows.
| Introduced in 1.0.0 |
Proxy | Text | Proxy server and port. | Introduced in 1.0.0 |
Proxy Credentials | Credentials | Credentials to be used for the proxy when the selected Proxy Type is HTTPS With Credentials. | Introduced in 1.0.0 |
Proxy CA Bundle File | Text | The path to a custom certificate bundle to use when establishing SSL/TLS connections with proxy. Visible only when the selected Proxy Type is "HTTPS With Credentials". | Introduced in 1.0.0 |
Webhook Payload (Bitbucket or Azure DevOps) | Text | Through this field the user can provide the Bitbucket or Azure DevOps webhook payload from which the task executed will extract the Added, Modified, and Removed Definition Lists. Visible only when the selected Import Mode is "Generic Webhook and Custom Mode". Note: Pass the webhook payload in this field only when integrating with Bitbucket or Azure DevOps. For all other Git webhook integrations, use the other three Definitions' List fields. | Introduced in 1.1.0 |
| Sign commit | Checkbox | Enables/Disables cryptographical signing of the commit with the provided private key. | Introduced in 2.3.0 |
| Signing Credentials | Credentials | The credentials used to sign the commit. The private key can be defined in the following ways.
| Introduced in 2.3.0 |
UC entity names must not contain Windows forbidden characters (< > : " / \ | ? *) when using tasks on Windows Agents, as these characters will cause Git operations to fail during file creation on the Windows filesystem.
Output Fields
Field | Type | Description | Introduced in Version |
|---|---|---|---|
Extension status | Text | Through this field, the user will be able to receive info about the internal status of execution, more detailed than the general task execution result code. Based on the status of the execution this field will be updated as follows:
| 1.1.0 |
Cancelation and Rerun
In case of a cancel event, the running action stops executing and returns a list of all the changes that took place until the cancellation request was received by the running extension instance (UAC definition exports or imports).
Exit Codes
The exit codes for this Universal Extension are described below.
| Exit Code | Status Classification Description | Status Description |
|---|---|---|
| 0 | Successful Execution | SUCCESS: Task Executed successfully. |
| 1 | Failed Execution | FAIL: Task Failed to execute with error(s) |
| 10 | Failed Execution | “Connection failed for API: <url>“ |
| 11 | Failed Execution | “Auth failed for action: <action details>, on API: <url>“ |
| 20 | Failed Execution | “Incorrect Field Data, see STDERR for more details“ |
| 21 | Failed Execution | “Some errors were produced during the data synchronization process: Task completed with failures. See Extension Output for more details." |
Environment Variables
Environment Variables can be set from Environment Variables task definition table. The following environment variables can affect the behavior of the extension.
Environment Variable Name | Description | Introduced in Version |
|---|---|---|
| UE_JAC_UC_HTTP_TIMEOUT | This environment variable expects an integer value and controls the maximum number of seconds for both establishing a connection to the UC and the maximum number of seconds the client will wait for the UC to send a response. | 2.0.3 |
| UE_FF_DISABLE_DEFAULT_COMMIT_PREFIX | This environment variable expects either True or False and controls whether to disable the default commit message prefix. | 2.0.0 |
| UE_VERBOSE_LOG_FILE | This environment variable expects a path to a file that will be used for storing the logging information. All log messages will additionally go to this file formatted exactly the same way as the existing messages. | 2.2.0 |
| GIT_AUTHOR_NAME | This environment variable expects the author's name of the commit message. | 2.3.0 |
| GIT_AUTHOR_EMAIL | This environment variable expects the author's email of the commit message. | 2.3.0 |
| GIT_COMMITTER_NAME | This environment variable expects the committer's name of the commit message. | 2.3.0 |
| GIT_COMMITTER_EMAIL | This environment variable expects the committer's email of the commit message. | 2.3.0 |
| UE_JAC_GIT_REPO_KEEP | This environment variable expects any value to be assigned to it, and it is used for keeping the repository that gets cloned during task execution. | 2.3.0 |
STDOUT and STDERR
STDOUT and STDERR provide additional information to the User. The populated content can be changed in future versions without notice. Backward compatibility is not guaranteed.
STDOUT
Table of Definitions
For better visualization, the extension provides a table that records the actual outcome of every file that is listed, exported, or imported. The columns of the table are:
| Type | Subtype | Name | Git Path | Status |
|---|---|---|---|---|
| UAC definition type | The Subtype of the definition, as shown in Universal Controller | The name of the definition | The git path the the definition will be exported to or imported from | The outcome of the action |
For example, execution of an Export to Git Repository Action for a workflow that has three tasks inside and belongs to a business service called 'jobs-as-code' will lead to the table below:
How To
Import Universal Template
To use the Universal Template, you first must perform the following steps
max_allowed_packet: Defines the maximum size of a single network packet that can be read or written by the server and clients.- Recommended setting: Ensure it is configured to a value at least 25% greater than the size of your largest imported integration
innodb_log_file_size: Determines the size of InnoDB redo log files. While this parameter has been simplified in recent MySQL versions, it's still relevant for MySQL versions prior to 8.0.30- Purpose: Prevents "BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size" errors that might appear on Universal Controller logs
- Recommended setting: Ensure 10% of the log file size exceeds your largest imported integration
Universal Agent Configuration (config/omss.conf):
max_msg_size: Specifies the maximum allowable size for messages. Messages exceeding the limit will not be accepted by the server.- Recommended setting: Ensure the configured value is 10% greater than your largest imported integration
Universal Controller Configuration
Universal Controller configuration file (tomcat/conf/uc.properties):
uc.universal_template.extension.maximum_bytes- Universal Controller UI Admin Panel: Administration → Properties → Universal Template Extension Maximum Bytes
- Recommended setting: Ensure the configured value is greater than the size of your largest imported integration
The deployment of an integration from Universal Controller to Universal Agents, can also be restricted by the JVM heap size of the Tomcat serving the Universal Controller. Ensure to configure the JVM heap size adequately.Things to consider.
- # of agents configured to accept the extension(s).
- # of agents configured to deploy on-registration and how many would be registering simultaneously.
- # of parallel, on-demand deployments, where deployment happens the first time the extension needs to execute on a specific agent.
This Universal Task requires the Resolvable Credentials feature. Check that the Resolvable Credentials Permitted system property has been set to true.
Import the Universal Template into your Controller:
Extract the zip file, you downloaded from the Integration Hub.
In the Controller UI, select Services > Import Integration Template option.
Browse to the “export” folder under the extracted files for the ZIP file (Name of the file will be unv_tmplt_*.zip) and click Import.
When the file is imported successfully, refresh the Universal Templates list; the Universal Template will appear on the list.
Modifications of this integration, applied by users or customers, before or after import, might affect the supportability of this integration. For more information refer to Integration Modifications.
Dependencies Manual Installation
External dependencies installation is not required from version 2.0 onwards. The following information is valid only for version 1.x.
On the Universal Agent that should execute this integration, perform pip install on the following libraries:
PyGithub: For exporting and importing UAC Definitions from GitHub
ruamel.yaml : The installation of the package is recommended but not mandatory for the "Export to Git Repository" action in YAML format. This package ensures that the exported UAC definitions are well-structured with optimal layout and indentation.
Configure Universal Task
For a new Universal Task, create a new task, and enter the required input fields.
Integration Modifications
Modifications applied by users or customers, before or after import, might affect the supportability of this integration. The following modifications are discouraged to retain the support level as applied for this integration.
Python code modifications should not be done.
Template Modifications
General Section
"Name", "Extension", "Variable Prefix", and "Icon" should not be changed.
Universal Template Details Section
"Template Type", "Agent Type", "Send Extension Variables", and "Always Cancel on Force Finish" should not be changed.
Result Processing Defaults Section
Success and Failure Exit codes should not be changed.
Success and Failure Output processing should not be changed.
Fields Restriction Section
The setup of the template does not impose any restrictions, However with respect to the "Exit Code Processing Fields" section.Success/Failure exit codes need to be respected.
In principle, as STDERR and STDOUT outputs can change in follow-up releases of this integration, they should not be considered as a reliable source for determining the success or failure of a task.
Users and customers are encouraged to report defects, or feature requests at Stonebranch Support Desk.
Document References
This document references the following documents.
| Document Link | Description |
|---|---|
| Universal Templates | User documentation for creating, working with and understanding Universal Templates and Integrations. |
| Universal Event Template | Use documentation for creating Universal Event Templates |
| Universal Tasks | User documentation for creating Universal Tasks in the Universal Controller user interface. |
| Credentials | User documentation for creating and working with credentials. |
| Resolvable Credentials Permitted Property | User documentation for Resolvable Credentials Permitted Property. |
Changelog
ue-jobs-as-code-2.3.0 (2025-10-27)
Enhancements
Added: Support using Git over SSH.Added: Add support for commit signing with SSH keys.Added: Numerous performance improvements.Added: Enhanced Robot testing with selective file upload for upload to Git keywords, Git custom library migrated to use pygit2, and decoupled Import test suite dependencies. (#43432)Added: Added new test cases for SSH and commit signing functionalities. (#49970)
Fixes
Fixed: Numerous bug fixes.Fixed: Fixed Import fail in "Insert or Update Mode" when task name is changed on Git. (#141401, #50207)Fixed: Fixed failing Wildcard Robot test cases. (#43432)
ue-jobs-as-code-2.2.0 (2025-09-18)
Enhancements
Added: The Import Mode field, which offers two options, "Generic Webhook and Custom Mode" covering the existing Import functionality with Add/Modify/Remove lists and Webhook Payloads, and "Insert or Update Mode" introducing new Import functionality with using a single Modify list for creating/modifying and option for regular expressions. (#45123)Added: The Environment Variable UE_VERBOSE_LOG_FILE used for storing the logging information to a file provided by the user. (#47862)Added: Alphabetical sorting on the output of the Dynamic Choice Fields. (#47720)Added: Enhancements in the exceptions handling in case of invalid Git repository for GitHub. (#49704)
Fixes
Fixed: Fix Remove functionality when importing, and Git path displayed on STDOUT, if the name of the definition changes in the file on the Git provider. (#47776)Fixed: Fetching all branch files when Git Repository Path is set for GitHub. (#47963)Fixed: Implement a proper resource sorting algorithm by using a modified version of topological sort. (#47818)Fixed: Fix issues where string fields that looked like booleans were converted to actual booleans during yaml to json conversion. (#139330, #48270)
ue-jobs-as-code-2.1.1 (2025-06-26)
Fixes
Fixed: Better handling of exported data when exporting to YAML
ue-jobs-as-code-2.1.0 (2025-01-03)
Enhancements
Added: New choice Definition Name (Wildcard) for Selection Method. This option can significantly improve performance in cases where the queried UC resources natively support wildcard filtering.
ue-jobs-as-code-2.0.4 (2024-09-12)
Fixes
Fixed: Fix getting workflow names through dynamic choice command taking too long
ue-jobs-as-code-2.0.3 (2024-08-14)
Fixes
Fixed: Properly handle URL unsafe characters inside definitions when exportingFixed: Auto-split large commits when exporting to Azure to avoid exceeding the maximum commit sizeFixed: Increase HTTP timeout (this value can now also be adjusted by setting the$UE_JAC_UC_HTTP_TIMEOUTenvironment variable)
ue-jobs-as-code-2.0.2 (2024-05-16)
Fixes
Fixed: Resolved issue where duplicate entries in UC definitions were not filtered out. (#36551).
ue-jobs-as-code-2.0.1 (2024-04-25)
Fixes
Fixed: Resolved compatibility issues with Linux systems utilizing glibc version 2.17 (#36552).
ue-jobs-as-code-2.0.0 (2024-03-21)
Breaking Changes
Added: Dependent libraries PyGithub and ruamel.yaml are now bundled within the extension and are not required to be installed manually. This is only possible from Controller/Agent version 7.4 onwards. (#35980).
Enhancements
Added: When Action is 'Export to Git Repository' commit all selected definitions with a single commit (#36044).Added: Feature Flag 'UE_FF_DISABLE_DEFAULT_COMMIT_PREFIX' is introduced to provide the capability of adjusting the default commit message prefix (#35074).
ue-jobs-as-code-1.2.1 (2023-01-23)
Fixes
Fixed: Http Code 404 when validating git file paths for Azure DevOps in action `Import from Git Repository` (#35567).Fixed: Wrongly picking up from `Webhook Payload`, committed files that include keywords `yaml` or `json` in their file path, for Azure DevOps in action `Import from Git Repository` (#35570).
ue-jobs-as-code-1.2.0 (2023-12-24)
Enhancements
Added: Support for Azure DevOps Services (Cloud Version) for Git Repos hosted on Azure DevOps Platform (#34932).
Fixes
Fixed: Error when executing an Import action specifying "*" in the added, modified or deleted uc definition list(#35167).
ue-jobs-as-code-1.1.0 (2023-11-09)
Enhancements
Added: Support Bit Bucket Git Service Provider (#32243).Added: Update output only field “Extension Status” with execution information (#32153).
Fixes
Fixed: Connect to GitLab client over Proxy with “Git SSL Verification” set to True (#32138).Fixed: Connect to GitHub Enterprise Server edition (#34507).Fixed: Handle exception HTTPError 500, raised when listing UC definitions with unresolved items (for instance: unresolved Credentials) (#32982).
ue-jobs-as-code-1.0.2 (2023-07-28)
Fixes
Fixed: The "Export to Git Repository" action now retains UAC definitions in a well-structured YAML format with optimal layout and indentation. Please check the Requirements section for more information.
ue-jobs-as-code-1.0.1 (2023-03-14)
Fixes
Fixed: Deletion of UC definitions via Webhook should not validate to-be-deleted files against specified Git Repository.
ue-jobs-as-code-1.0.0 (2023-03-09)
Added: Initial Version