Introduction
As a part of the constant endeavor to enhance the ease of working with Kyvos, the Continuous Integration and Continuous Deployment (CI/CD) Utility is created to automate the end-to-end migration versioning of Kyvos entities (like Semantic Models, DatasetRelationships, and RegisterDataset) from Kyvos Source environment to Kyvos Target environment Relationships, Datasets, etc., using Git as a versioning tool.
The CI/CD Utility comprises of the following two utilities:
The Export Utility is created for the semantic model designers to export the entities specified in the configuration file from Kyvos and push them to the feature branch of the user repository. The Utility is based on a Java to execute the REST API to export the required entities from Kyvos in the form of XML files, stage into a local folder, and finally, push these changes to a user-specified Git repository.
The Deploy Utility is created for the Admin users to fetch entities planned for deployment from the Git repository and deploy the entity XML files to the target Kyvos environment. Jenkins is used for automating the deployment from GIT Repository to Kyvos. Jenkins job triggers the Deploy executable file, which triggers REST API using java to Deploy the entity XML files to Kyvos target environment.
Prerequisites
To use the Export utility, you must have the following.
Git Bash: It is a package that installs Bash, some common bash utilities, and Git on an operating system. This is needed to execute the Git commands on your system.
GitLab: Account and Repository with main and feature branch.
Setup details
The utility setup is provided as a single .zip file (Linux) that you can unzip at any location on any computer.
On extracting the setup, you will see the following folders and files:
Linux computer:
1.conf
2.input
3.lib
4.ExportKyvosEntities.sh
5.DeployKyvosEntities.sh
6.output
Setting up parameters for CICD Utility
In the Linux machine and navigate to where the setup files are extracted.
Navigate to the conf folder and open the serverDetail.properties file for editing. Here, provide the values for the following parameters, and save the file.
KYVOS_URL= http://<Server IP>:8081/kyvos/rest/
USERNAME= <Name of user>
PASSWORD= <Kyvos URL password>
Navigate to the input folder and open the input.json file for editing. Here, provide the values for the following parameters, and save the file.
Snippet of input.json file
It can be used to migrate entities from one Kyvos deployment (Source) to another Kyvos deployment (Target). It uses Gitlab to store versions of Kyvos entities in XML format.
It also provides integration with Bitbucket repositories.
It is a Java-based utility and uses Kyvos REST APIs to export the entities from source Kyvos deployment and to import the entities to target Kyvos deployment. It is designed to be used in Linux system.
It is recommended to use Kyvos user credentials having administrative privileges to import and export all sorts of entities.
The CI/CD Utility comprises the following two utilities:
Export Utility: It fetches entities from Kyvos deployment in XML format, stores them in a local folder, and then pushes them to the configured Git repository. It has a configuration file to define all entities that are to be fetched along with source Kyvos deployment and git repository details.
Import Utility: It uses Jenkins to automate the import of entities from Git repository to target Kyvos deployment. Jenkins pipeline is configured in Gitlab server to pull the entities from Gitlab to the local file system. Jenkins then launches the import utility shell script which then finally imports the entities from file system to target Kyvos deployment.
Utility bundle details
The utility bundle contains a single zip file having following folders and files within it:
Conf folder: It contains serverDetailExportUtility.properties , serverDetailImportUtility.properties and cicdLogs.properties
Input folder contains input.json file to be used for configuring the entities to be exported and Gitlab server details.
Lib folder: folder containing required libraries for the utility
output folder: initially blank folder and to be used for placing exported entities XML file when not pushing into Gitlab server.
ExportKyvosEntities.sh: Script file to launch Export utility
ImportKyvosEntities.sh: Script file to launch Import utility
Export Utility
Prerequisites
Git Bash: It is a package that installs Bash, some common bash utilities, and Git on an operating system. This is needed to execute the Git commands on your system.
GitLab: Git server with main and feature branches.
Setting up Export Utility
Extract the setup zip.
Configure source Kyvos deployment details in serverDetailExportUtility.properties file in Conf folder. This file needs the details below to be filled in. If the details are not provided in this file, then alternatively these details can be provided as an argument to the export utility script.
KYVOS_URL = <YourKyvosURL>/rest/
USERNAME = <KyvosUserName>
PASSWORD = <KyvosUserPassword>
Configure input.json within input folder to define the entities to be exported. The following table provides details of the parameters
...
in the input.json file.
...
Parameter
...
Description
SEMANTIC_MODEL_DETAILS
Provide
...
Scenarios and examples are mentioned after this table in cases
where multiple entities need to be exported.
...
DATASET_RELATIONSHIP_DETAILS
...
the execute permission on the ExportKyvosEntities.sh file, if not already provided (chmod +x ExportKyvosEntities.sh)
Parameter | Description | |
EXPORT_SEMANTIC_MODELS | Defines whether to export Semantic Model entities or not.
| |
SEMANTIC_MODEL_DETAILS | Provide details of the semantic model which needs to be exported in the following format. "FolderName":[" | DatasetRelationshipNameSemanticModelName"], |
DATASET_DETAILS
| Provide the details of the Dataset which needs to be exported in the format "FolderName":["DatasetName"], Scenarios and examples are mentioned after this table in cases where multiple entities need to be exported. | |
WB_DETAILS
| Provide the details of the WB
“FolderName” should be the name of Kyvos entity folder name to be exported. "SemanticModelName": Comma separated entity names existing within the folder Example {"Folder1": [ “Model1”,” Model2”], “Folder2”: [“Model3”]} | |
EXPORT_DATASET_RELATIONSHIPS
| Defines whether to export Dataset Relationship entities or not.
| |
DATASET_RELATIONSHIP_DETAILS
| Provide details of the Dataset Relationship which needs to be exported in the | format “FolderName”following format. "FolderName":[ | “WorkBookName”]
EXPORT_SEMANTIC_MODELS
| Allows you to export semantic model objects. Set the value as Y to enable export, else, set it as N. | |
EXPORT_DATASET_RELATIONSHIPS
| Allows you to export dataset relationship objects. Set the value as Y to enable export, else, set it as N. | |
EXPORT_DATASETS
| Allows you to export dataset objects. Set the value as Y to enable export, else, set it as N. | |
EXPORT_WB | Allows you to export workbook objects. Set the value as Y to enable export, else, set it as N. | |
GIT_LOCAL_REPO_PATH | The path of the GITRepo folder to be used as staging location. The folder is available in the Export utility folder. Provide the path of the GIT Repo folder. For example, “C:/CICDUtility/Export/GITRepo” Note: Please use the forward slash (/) in the repo path as mentioned in the example and config file snippet above. | |
GIT_USERNAME | GitLab username to connect with GIT Repo. | |
GIT_FEATURE_BRANCH_NAME | GitLab feature branch name where the XML entities will get exported. For example, “working” | |
GIT_PUSH | Allows you to push the exported data to GitLab. Set the value as Y to push the exported data to GitLab. To export to only to the local output folder (and not to GitLab), set the value as N. | |
GIT_FEATURE_BRANCH_CLEAN | This parameter allows you to clean the GIT Feature branch before a fresh export. The default value is N. To enable cleaning, set the value as Y. | |
GIT_REPONAME | GitLab Repo Name where the entities will get exported. | |
GIT_TOKEN | The Personal Access Token for Authentication with user’s GIT account. In case you do not have the Personal Access token, you can create it using the steps explained in the Append. | |
GIT_URL | Git url to be mentioned |
...
Below are several scenarios to export multiple semantic models, datasetrelationships, and dataset entities in single export using the input.json if the respective values are set as Y.
...
Export single entity present from a single folder
"SEMANTIC_MODEL_DETAILS": { "Folder1" : [ “Model1”] }
"DATASET_RELATIONSHIP_DETAILS": { "Folder1" : [ “DatasetRelationship1”] }
"DATASET_DETAILS": { "Folder1" : [ “Dataset1”] }
Export multiple entities from a single folder
...
"DatasetRelationshipName"], “FolderName” should be the name of Kyvos entity folder name to be exported. "DatasetRelationshipName": Comma separated entity names existing within the folder Example {"Folder1": [ “DRelationship1”,” DRelationship2”], “Folder2”: [“DRelationship3”]} | |
EXPORT_DATASETS | Defines whether to export Dataset entities or not.
|
DATASET_DETAILS | Provide details of the Dataset which needs to be exported in the following format. "FolderName": ["DatasetName"], “FolderName” should be the name of Kyvos entity folder name to be exported. "DatasetName": Comma separated entity names existing within the folder Example {"Folder1": [ “Dataset 1”,” Dataset 2”], “Folder2”: [“Dataset 3”]} |
EXPORT_WB | Defines whether to export Workbooks or not.
|
WB_DETAILS | Provide details of the Workbooks which need to be exported in the following format. "FolderName": ["Workbook"], “FolderName” should be the name of Kyvos entity folder name to be exported. "Workbook": Comma separated entity names existing within the folder Example {"Folder1": [ “workbook1”,” workbook2”], “Folder2”: [“workbook3”]} |
GIT_PUSH | Defines whether to push the exported entities into Gitlab or not.
|
GIT_URL | Server URL |
GIT_LOCAL_REPO_PATH | Provide path of a folder to be used as staging location. For example, “C:/CICDUtility/Export/GITRepo” Note: Please use the forward slash (/) in the repo path. |
GIT_FEATURE_BRANCH_NAME | Gitlab feature branch name where entities will get exported. |
GIT_FEATURE_BRANCH_CLEAN | Defines whether to clean the GIT Feature branch before a fresh export. The default value is N.
|
GIT_REPONAME | Gitlab repository name where the entities will get exported. |
GIT_USERNAME | Gitlab username to connect with GIT Repo. |
GIT_TOKEN | The Personal Access Token for Authentication with user’s GIT account. In case you do not have the Personal Access token, you can create it using the steps explained in the Append. |
...
Example configurations for different scenarios
Export All entities from one or more folders
"SEMANTIC_MODEL_DETAILS": {"Folder1" : [
...
],
...
“Folder2”: [] }
"DATASET_RELATIONSHIP_DETAILS": { "Folder1" : [
...
],
...
“Folder2” : [] }
...
“DATASET_DETAILS": { "Folder1" : [
...
],
...
“Folder2” : [] }
Export single/multiple entities from multiple foldersROOT (when entities are not a part of any folder)
"SEMANTIC_MODEL_DETAILS": { "
...
ROOT" : [
...
“Model4”, “Model5”] }
"DATASET_RELATIONSHIP_DETAILS": {"
...
ROOT": [
...
“DatasetRelationship4”,
...
“DatasetRelationship5”]}
"DATASET_DETAILS": { "
...
ROOT" : [
...
“Dataset4”, “Dataset5”] }
Export All entities from one or more folders
"SEMANTICALL entities, which includes all entities at ROOT and all folders with all entities
“SEMANTIC_MODEL_DETAILS": {
...
}
...
“ DATASET_RELATIONSHIP_DETAILS
...
": {
...
}
“DATASET_DETAILS": {
...
}
...
Export single/multiple entities from ROOT (when entities are not a part of any folder)
"SEMANTIC_MODEL_DETAILS": { "ROOT" : [ “Model4”, “Model5”] }
"DATASET_RELATIONSHIP_DETAILS": { "ROOT" : [ “DatasetRelationship4”, “DatasetRelationship5”] }
"DATASET_DETAILS": { "ROOT" : [ “Dataset4”, “Dataset5”] }
...
Export ALL entities, which includes all entities at ROOT and all folders with all entities
“SEMANTIC_MODEL_DETAILS": { }
“ DATASET_RELATIONSHIP_DETAILS ": { }
“DATASET_DETAILS": { }
Executing ExportKyvosEntities on Linux
To execute the utility on a Linux computer, perform the following steps.
In the Linux machine, go to the folder where the utility was unzipped.
Provide the execute permission on the ExportKyvosEntities.sh file, if not already provided (chmod +x ExportKyvosEntities.sh)
Run the ./ExportKyvosEntities.sh command.
You will see logging, semantic model validation, and success messages on the successful execution of the utility. In case of any exception, you will see failed messages, and all newly created folders will be deleted. Please get in touch with the Kyvos support team in case of an exception.
ExportKyvosEntities.shfile
The Export utility starts executing. Once the export is complete, you can check the execution logs in the output folder.
The following figure shows a snippet of the Export Utility execution.If the GITPUSH parameter is set as Y in the input file, then all the entity XML files will get exported to the GitLab Feature branch in the following order.
A GIT PULL is performed from the feature branch specified in the input file. So that the remote and local repository (GITRepo) are in sync.
The entities are exported to the GITRepo folder from Kyvos, which is a local repository clone of the GitLab repository.
Entities are then pushed to the GitLab feature branch; we have used the working feature branch in this case
If the GITPUSH parameter is set as N in the input file, then the entities are directly exported to the Output folder. No GIT PULL and GIT PUSH will be performed in this case.
Deploy Entities Utility
We can deploy entities using two methods
We can deploy through shell file when entities present in local machine
We can deploy using jenkins pipeline which configure with gitlab
Prerequisites
To use the Deploy utility, you must have the following.
Git Bash: It is a package that installs Bash, some common bash utilities, and Git on operating system. This is needed to execute the Git commands on your system.
gitlab: Account and Repository with the main branch.
Jenkins: For automated execution of the Deploy utility, based on a trigger from gitlab.
Deploying entities using shell file
Parameters for Deploy Utility
We need to pass these parameters while running deploy utility on Linux on command line
KYVOS_URL= http://<Server IP>:8081/kyvos/rest/
USERNAME= <Kyvos Username>
PASSWORD= <Kyvos User Password>
KyvosEntitiesPath=<Path of KyvosEntities store in local machine>
Executing deploy on Linux
To execute the utility on a Linux computer, perform the following steps.
In the Linux machine Go to the folder where the utility was unzipped.
Provide the execute permission on the DeployKyvosEntities.sh file, if not already provided (chmod +x DeployKyvosEntities.sh).
Run the ./DeployKyvosEntities.sh $KyvosUrl $Username $Password $KyvosEntitiesPath command.
You will see logging, semantic model validation, and success messages on the successful execution of the utility. In case of any exception, you will see failed messages, and all newly created folders will be deleted. Please get in touch with the Kyvos support team in case of an exception.
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Note KyvosEntitiesPath is the path where entities store in local machine and it by default present in output/timestamp_folder/Repo_Name/KyvosEntities |
Executing Deploy Utility from jenkins
Creating new Project in Jenkins. In case the Jenkins job is not Integrated with GitLab Repository, see the section Gitlab settings to integrate with Jenkins. Once the above steps are completed, you can execute the Deploy Utility.
Trigger the Deploy Utility by executing the following pipeline using the Jenkins jobs.
Code Block |
---|
sh "java -cp <CICD utility jar file path>:<Utility commons jar file path> com.kyvos.deploy.DeployKyvosEntities ${sourceKyvosURL} ${sourceKyvosUser} ${sourceKyvosPassword} ${kyvosEntitiesPath}" |
Create a pipeline mention in below image
...
In the command above,
Add these parameters in Jenkins pipeline:
Click on project as parameter then add parameter given below
kyvosEntitiesPath represents the directory path storing Kyvos entities within the Jenkins workspace dedicated to your project. During the Jenkins workflow, data is fetched from the main GitHub repository and stored in this location. Subsequently, this directory serves as the source for deploying data to the intended environment. It's crucial to run the Jenkins jobs initially to establish the workspace for your new project.
KyvosURL is the URL of the target Kyvos environment.
KyvosUsername is the name of the native user with admin access to the target Kyvos environment.
KyvosPassword is the password of the native user with admin access to the target Kyvos environment.
The job is automatically triggered by webhook whenever you push entities to main branch.
The following figure shows Kyvos Monitor showing updated Files, Relationship, and Cube Entity after the execution of Deploy Utility.
...
Audit logs of entities updated in Kyvos
Appendix
The Personal Access Token is required for authentication of Export Utility with Git. You are required to provide this in the Export Utility config file, as explained in the Export Utility section.
To create a Personal Access Token in GitLab, perform the following steps.
In your GitLab account, navigate to Settings.
On the left pane, click the Developer settings option, select the Personal access tokens from the left pane, and click Generate new token.
Give the token a Descriptive name, select the Scopes which defines the access for the Personal tokens, and then click the Generate token.
A token is generated. Make sure you copy your new personal access token to be used in Export Utility.
You can also Update, Regenerate, Revoke, or Delete the token using the options available on the page.
Creating new Project in Jenkins
To create a new project in Jenkins, perform the following steps.
Login to your Jenkins account.
Install the following plugins:
Git client plugin
GitHub API
GitHub Branch Source Plugin
GitHub plugin
Genric Webhook plugin
If the plugins are not installed while initializing Jenkins. Go to Manage Jenkins >Manage Plugins and install the plugins.
Click New Item from the top left of your dashboard.
Enter the name of the item you want to create, select Pipeline , and click OK. The project is created.
Navigate to the newly created project and select the Configure option, as shown in the following figure.
On the General tab, select the GitHub Project check box and provide the URL of the GitHub/GitLab repository in the Project url field, as shown in the following figure.
On the Source Code Management tab, select the Git option on the left and provide your Git Repository URL and Credentials in the corresponding fields.
Change the Branch Specifier as shown in the below screenshot refs/head/{nameofbranch} this is the branch we intend to build using Jenkins. In this example, we have selected main to Build.
Select the Repository Browser as Auto.
In Additional Behaviours, select the Wipe out repository & force clone option to erase the local repository and clone the fresh repository every time to avoid inconsistency.
On the Build Triggers tab, select GitHub hook trigger for GITScm polling option. This triggers a Jenkins job when the GitHub webhook relays any payload or If you are using genric webhook use can select on genric webhook trigger and genrate a token .
It is used to execute the Deploy Utility as soon entities are merged from the Feature branch to the Master branch in GitHub repository mentioned in Jenkins above.
15. On the Build tab, select the Pipeline command and create the pipeline (explained in the Deploy Utility section) to execute the Utility.
...
Executing Export Utility
Code Block |
---|
Run ./ExportKyvosEntities.sh $KyvosUrl, $Username, $Password |
The parameters are optional, if set in serverDetailExportUtility.properties file. If values are given at both places, script arguments take the preference.
You can access the execution log file located within the "conf/log" folder, which contains the file named "cicd.log".
Steps Performed by Export Utility
If the GITPUSH parameter is set as Y, then all the entity XML files will get exported to the GitLab Feature branch in the following order.
A GIT PULL is performed from the feature branch specified in the input file. So that the remote and local repository (GITRepo) are in sync.
The entities are exported to the GITRepo folder from Kyvos, which is a local repository clone of the GitLab repository.
Entities are then pushed to the GitLab feature branch.
If the GITPUSH parameter is set as N in the input file, then the entities are directly exported to the Output folder. No GIT PULL and GIT PUSH will be performed in this case.
Import Utility
The import utility works in two steps.
Step 1: On changes in configured Gitlab branch, Jenkins pipeline triggers to pull the changed files in local file system, it then launches the ImportKyvosEntities.sh script.
Jenkins pipeline is required to automate
the changes identification in configured Gitlab branch and
pull the changed entity files in configured folder within local file system
to launch the ImportKyvosEntities.sh script
Step 2: On execution ImportKyvosEntities.sh script reads all the entities xml files placed in configured folder and uses Kyvos REST APIs to import them in target Kyvos deployment.
In case Jenkins pipeline is not configured, then Step 2 can still work on launching ImportKyvosEntities.sh independently.
Prerequisites
Git Bash: It is a package that installs Bash, some common bash utilities, and Git on an operating system. This is needed to execute the Git commands on your system.
GitLab: Git server with main and feature branches.
Jenkins: For automated execution of the Import utility script, based on a trigger from Gitlab.
Setting up Import Utility
Extract the setup zip.
Configure source target Kyvos deployment details in serverDetailImportUtility.properties file in Conf folder. This file needs the details below to be filled in. If the details are not provided in this file, then alternatively these details can be provided as an argument to the import utility script.
KYVOS_URL = <YourKyvosURL>/rest/
USERNAME = <KyvosUserName>
PASSWORD = <KyvosUserPassword>
Provide the execute permission on the ImportKyvosEntities.sh file, if not already provided (chmod +x ImportKyvosEntities.sh)
Executing Import Utility separately without Jenkins to perform step 2
Code Block |
---|
Run ./ImportKyvosEntities.sh $KyvosEntitiesPath $Username $Password $KyvosUrl |
KyvosEntitiesPath is a local machine’s GitLab Repo folder path where entities are stored on pull. This is mandatory parameter. The other parameters are optional, if set in serverDetailImportUtility.properties file. If values are given at both places, script arguments take the preference.
You can access the execution log file located within the "conf/log" folder, which contains the file named "cicd.log".
Jenkins job setup and integration with GitLab Repository
In case the Jenkins job is not created and configured, see the section Creating new Project in Jenkins.
In case the Jenkins job is not Integrated with GitLab Repository, see the section Gitlab settings to integrate with Jenkins.
Once the above steps are completed, you can execute the Import Utility via Jenkins.
Executing Import Utility via Jenkins
Trigger the Import utility by executing the following pipeline using the Jenkins job. Once configured, the job will automatically be triggered by webhook whenever you push entities to main branch.
Code Block |
---|
sh "jenkinsWorkspace/ImportUtilityFilePath ${KyvosEntitiesPath} ${KyvosUsername} ${KyvosPassword} ${KyvosURL}" |
All the parameters are mandatory here. Add these parameters in Jenkins pipeline:
KyvosEntitiesPath: represents the directory path storing Kyvos entities within the Jenkins workspace dedicated to your project. During the Jenkins workflow, data is fetched from the main GitLab repository and stored in this location. Subsequently, this directory serves as the source for deploying data to the intended environment. It's crucial to run the Jenkins jobs initially to establish the workspace for your new project
KyvosUsername is the name of the native user with admin access to the target Kyvos deployment.
KyvosPassword is the password of the native user with admin access to the target Kyvos deployment.
KyvosURL is the URL of the target Kyvos deployment.
Jenkins pipeline
...
Code Block |
---|
pipeline {
agent any
stages {
stage ('Environment Details') {
steps {
sh '''
env | grep -e PATH -e JAVA_HOME
which java
java -version
mvn –version"” }}
stage('Checkout') {
steps {
checkout (
[$class: 'GitSCM',
branches: [[name: '*/your_branch_name']],
extensions: [], userRemoteConfigs:
[[credentialsId: 'your_credential_id',
url: 'your_git_url']]] ) } }
stage('Build') {
steps {
script{
dir('jenkinsWorkSpacePath/cicdUtilityPath') {
sh "pwd"
sh " jenkinsWorkSpacePath /cicdUtilityPath/ImportKyvosEntities.sh ${kyvosEntitiesPath} ${KyvosUsername} ${kyvosPassword} ${KyvosURL}" } } } } } } |
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Note Please replace your “jenkinsWorkSpacePath” with your Jenkins workspace and "cicdUtilityPath" with the actual path of your CICD utility directory inside Jenkins workspace where you have stored the CI/CD utility in above script. |
Kyvos Monitor Image shows updated audit entries for imported Datasets, Relationship, and Semantic Model entities after the execution of Import utility.
Appendix
Creating Personal Access Token in GitLab
The Personal Access Token is required for authentication of Export Utility with Git. You are required to provide this in the Export Utility config file, as explained in the Export Utility section. To create a Personal Access Token in GitLab, perform the following steps.
To create a Personal Access Token in GitLab, perform the following steps.
In your GitLab account, navigate to Settings.
On the left pane, click the Developer settings option, select the Personal access tokens from the left pane, and click Generate new token.
Give the token a Descriptive name, select the Scopes which defines the access for the Personal tokens, and then click the Generate token.
A token is generated. Make sure you copy your new personal access token to be used in Export Utility.
You can also Update, Regenerate, Revoke, or Delete the token using the options available on the page.
Creating new Project in Jenkins
To create a new project in Jenkins, perform the following steps.
Login to your Jenkins account.
Install the following plugins:
Git client plugin
GitHub API
GitHub Branch Source Plugin
GitHub plugin
Genric Webhook plugin
If the plugins are not installed while initializing Jenkins, go to Manage Jenkins >Manage Plugins and install the plugins.
Click New Item from the top left of your dashboard.
Enter the name of the item you want to create, select Pipeline , and click OK. The project is created.
Navigate to the newly created project and select the Configure option, as shown in the following figure.
On the General tab, select the GitHub Project check box and provide the URL of the GitHub/GitLab repository in the Project url field, as shown in the following figure.
On the Build Triggers tab, select Generic Webhook Trigger. This triggers a Jenkins job when the GitLab webhook relays any payload. If you are using a generic webhook you can select the generic webhook trigger option.
Provide Jenkins credential id in the Token section or generate a token id in Token Credential section by clicking on ADD button and provide credentials.
It is used to execute the Import Utility as soon entities are merged from the Feature branch to the Master branch in GitHub repository mentioned in Jenkins above.
On the Build tab, select the Pipeline Script command and create the pipeline (explained in the above section) to execute the Utility.
Click the Save button to save your changes
GitLab settings to integrate with Jenkins
Webhooks act as a trigger for the Jenkins job to execute the Import Utility if the defined event happens.
To integrate GitLab with Jenkins, perform the following steps.
In your GitLab Account, select the repository that you want to integrate with Jenkins and go to the Settings tab.
Select the Webhooks option from the left pane.
Click the Add new webhook option.
In the URL field, enter the Jenkins URL. You must add /generic-webhook-trigger/invoke to this and provide secret token credential id or that you have generated in jenkins while configuring webhooks, as shown in the figure below.
Select the Pushes in the events and click the Add Webhook option.
Select event Push wildcard expression in that mention the main branch name
Click the Save changes option to apply the changes.
Then, click on the Test option to test the webhook.