CI/CD pipeline setup

This topic describes how to set up a CI/CD pipeline that integrates with BMC AMI DevX Code Pipeline. The setup involves creating a new pipeline job in your chosen CI/CD tool, defining the necessary parameters, and configuring how it interacts with Code Pipeline and related tools.

Task 1: Create a pipeline job

• Jenkins: Create a new Pipeline project (or Multibranch Pipeline if Git-driven).
• Azure DevOps: Create a pipeline (YAML) in your project.
• GitHub Actions: Create a workflow YAML under .github/workflows.
• GitLab: Add a .gitlab-ci.yml pipeline definition.

Task 2: Configure the pipeline parameters

Your pipeline must be able to accept parameters from Code Pipeline webhooks for Promote and Generate events. Define parameters so they can be passed to pipeline stages.

Runtime parameters (from Code Pipeline webhooks)

Code Pipeline automatically passes the following parameters when a webhook triggers your pipeline:

Parameter	Purpose	Source webhook variable
ISPW_Stream	Stream name	$$stream$$
ISPW_Application	Application name	$$application$$
ISPW_SubApplication	Subapplication (if defined)	$$subApplication$$
ISPW_Release	Release container identifier	$$release$$
ISPW_Assignment	Assignment container identifier	$$assignment$$
ISPW_Src_Level	Lifecycle level promoted from (for example, from DEV1 to QA)	$$level$$
ISPW_Operation	Operation type (Promote or Generate)	$$operation$$
ISPW_Set_id	Unique ID of the set created by the operation	$$setID$$
ISPW_Owner	TSO ID of the user who initiated the action	$$owner$$

Configuration parameters (set in pipeline configuration or secrets)

The following parameters configure connectivity, testing, and quality analysis. You define these parameters in your CI/CD tool; they do not come from webhooks.

Parameter	Purpose
CES_Url	CES endpoint URL
CES_Token	Authentication token for CES (stored securely)
HCI_Conn_ID	Host Communication Interface connection ID
HCI_Token	HCI token (stored securely)
ISPW_Runtime	Code Pipeline runtime environment name
ISPW_Changed_Programs_File	JSON file listing changed components (used for Intelligent Test Execution)
CC_Repository	Repository or data set for code coverage
MF_Source	Workspace folder to download mainframe sources
Git_URL	Base Git server URL
Git_Project	Git project name
Git_Branch	Git branch for test assets
Git_Credentials	Secure Git credentials
TTT_Base_Folder	Base folder for Total Test repository
TTT_Vt_Folder	Folder for virtualized test scenarios
TTT_Vt_Environment	CES environment ID for virtualized tests
TTT_Vt_TargetSonarResults	Sonar results file name for virtualized tests
TTT_NonVirtualized_Folder	Folder for non-virtualized tests
TTT_NonVirtualized_Environment	CES environment ID for non-virtualized tests
TTT_NonVirtualized_TargetSonarResults	Sonar results file name for non-virtualized tests
TTT_Sonar_Results_File	Sonar-compatible results file (for example, generated.cli.suite.sonar.xml)
SQ_Scanner_Name	SonarQube scanner name in a CI environment
SQ_Server_Name	SonarQube server name

Task 3: Configure a webhook

The integration of CI/CD with Code Pipeline relies critically on webhooks to trigger pipelines and communicate events. Below is a fully detailed view:

Webhook setup in CES or Code Pipeline

• Configure a webhook in Code Pipeline or CES to send events (such as promote or generate) to your CI system endpoint (such as Jenkins, or Azure DevOps).
• Webhook payload must include runtime parameters: assignment, stream, application, ISPW_Changed_Programs_File (the JSON of changed programs) and so on.
• In Jenkins, the webhook callback must map to the correct job endpoint (for example, http://jenkins.mycompany.com/job/my-pipeline/buildWithParameters). For more information, see Jenkins Plugin.
• If Jenkins CSRF is enabled, the webhook must include Jenkins crumb in the header or disable CSRF for this path.
• The webhook may be synchronous or asynchronous. For generate operations, you can include event notification parameters (events.name, events.body) so that CES calls back after completion. The Jenkins plug-in supports registering webhooks and waiting for callback via ispwRegisterWebhook or ispwWaitForWebhook constructs.

Event-driven sequences (callback or polling)

• For operations such as generate, consider waiting until the set is built before proceeding, using webhook callbacks or polling (GetSetInfo) to detect completion. The Jenkins plugin supports synchronous callback logic.
• The payload event body might contain a $$setid$$ placeholder, which CES callback substitutes with the actual set ID.
• Use ISPW_Changed_Programs_File from the event payload to drive Intelligent Test Execution in Total Test. Run tests relevant to changed programs only.

Connect Code Pipeline webhooks

• In CES, configure webhooks to trigger pipelines when developers promote or generate components.
• Ensure webhook payload includes parameters like assignment, set ID, and changed components file.
• Test the webhook by promoting a sample component and confirming the pipeline starts.

Summary of the setup procedure

This section summarizes the CI/CD setup procedure based on your CI/CD tool.

Jenkins

1. In Jenkins, create a Pipeline job.
2. Mark the job as parameterized and add the parameters listed above.
3. Use a Jenkinsfile (stored in Git or inline) to define pipeline logic.
4. Install required plugins:
   • BMC AMI DevX Code Pipeline Operations
   • BMC AMI DevX Source Code Download
   • SonarQube Scanner

Azure DevOps

1. Create a new pipeline in your project.
2. Use YAML format and define parameters at the top.
3. Install or configure self-hosted agents with Workbench CLI and Total Test installed.
4. Add PowerShell tasks to call CLI scripts. For more information, see Powershell scripts to make use of the BMC AMI DevX CLIs and REST APIs.

GitHub Actions

1. Add a new workflow file in .github/workflows/ci.yml.
2. Use on: push or connect Code Pipeline webhooks to GitHub.
3. Configure a self-hosted runner with CLI tools installed. To use BMC AMI DevX CLIs an REST APIs, see Install Workbench CLI
4. Store tokens in GitHub Secrets (SONAR_TOKEN, CES_PAT).