Variables for Universal Connector

(BMC.DB2.SPE2404) 

You can use variables to dynamically provide input for SQL Assurance steps.

You can specify user-defined variables in one of the following formats:

  • VARIABLE
  • ${variable}
  • $[variable]

Related topics

Command and syntax reference

Types of variables

This section describes the following types of variables:

Azure DevOps variable group and pipeline variables

These variables are in VARIABLE format. The variable name is in uppercase.

SQL Assurancereplaces these variables with the default or user-defined value of the corresponding variable name.

Example

You can create a variable group that can have several variables defined to it, like USER_ID, with a default value, TESTER1. When you run the pipeline, the value of the variable, USER_ID, uses TESTER1.
You can create a pipeline variable, JOB_ID, with a default value, MME12345. When you run the pipeline, the value of the pipeline variable, JOB_ID, is either MME12345 (the default value of the JOB_ID parameter) or the value that you enter.

Best practice

We recommend that you define the variable name in uppercase to distinguish it from an actual value in the config YAML file.

To create variable group variables

  1. On the Azure DevOps dashboard, click Pipelines to expand it.
  2. Click Library.
  3. Click +Variable group.
  4. Enter the variable group name.
  5. (Optional) Enter a description.
  6. Click +Add.
  7. Enter a variable name.

  8. Enter a variable value.

    Important

    If this is a password, select the Keep this value secret check box.

  9. Click Save.

To create pipeline variables

  1. On the Azure DevOps dashboard, click Pipelines to expand it.
  2. On the Pipelines tab, click All to show a list of all the pipelines.
  3. Select a pipeline to open a list of all runs for the specified pipeline.
  4. On the Runs tab, click Edit in the upper right-hand corner to edit the pipeline before running.
  5. Click Variables in the upper right-hand corner.
    1. In the Variables dialog box, click + Add.
    2. In the New variable dialog box, enter the variable name.

    3. Enter a variable value.

      Important

      If this is a password, select the Keep this value secret check box.

      If this is a value that will be replaced with each run, select the Let users override this value when running this pipeline check box.

  6. Click OK .
  7. Click Save.

GitHub Actions Variable, Secrets, and Workflow variable

These variables are in VARIABLE format. The variable name is in all caps.

SQL Assurancereplaces these variables with the default or user-defined value of the corresponding variable name.

The utilization of secrets and variables is useful if you want to reuse the same property values in multiple workflows or change the property value frequently.

Best practice

We recommend that you define the variable name in uppercase to distinguish it from an actual value in the config YAML file.

To create variables for use with multiple workflows:

  1. In your GitHub repository, select Settings.
  2. Under Security, expand Secrets and Variables.
  3. Select Actions.
  4. Select the Variables tab and click New repository variable.
  5. Enter the variable name and value, and click Add variable.

To create secrets for use with multiple workflows:

  1. In your GitHub repository, select Settings.
  2. Under Security, expand Secrets and Variables.
  3. Select Actions.
  4. Select the Secrets tab and click New repository secret .
  5. Enter the secret variable name and value, and click Add secret.

To create environment variables for a single workflow:

  1. In your workflow scripts, define the key: env: .
  2. Under env:, define variableName: value.
Example

env:
   JOB_ID: Job0001

GitLab CI/CD variables

(BMC.DB2.SPE2501)

These variables are in VARIABLE format and are all uppercase. SQL Assurance replaces these variables with the user-defined value of the corresponding variable name. You can use these variables to reuse the same property values in multiple pipelines or change the property value frequently.

GitLab provides predefined CI/CD variables for use in your pipeline configuration and job script. You can use these without declaring them first in your pipeline YAML file.

For more information on all GitLab CI/CD variable types, see the GitLab documentation.

Best practice

We recommend that you define the variable name in uppercase to distinguish it from an actual value in the config YAML file.

To create variables for use with multiple pipelines

For variables referenced in the config yaml file and those with sensitive values, follow these steps:

  1. From the GitLab Project Settings menu, select CI/CD.
  2. Expand Variables.
  3. Click Add variable.
  4. Specify the following variable options:
    • Type: Variable (default)
    • Environment: All (default)
    • Visibility: Select visible, masked, or masked & hidden, depending on the sensitivity of your variable value
    • Flags: Expand variable reference
    • Description: Enter a description of the variable.
    • Key: Specify your variable name.
    • Value: Enter a variable value.

  5. Click Add variable.

    Important

    Define and store security-sensitive variables only if you select masked visibility.

     

To create pipeline variables for use in a single pipeline

For variables referenced in the pipeline YAML file, follow these steps:

  1. In your pipeline script, define the key: variables.
  2. Define the variable name under the variables keyword by indenting the variableName: and "value".
Example
variables:
  PIPELINE_NAME: "pipeline-sql-assurance-dynamic-sql"                             
  CONFIG_FILE: "configFiles/Config_SQL_Assurance_Dynamic_SQL.yml"

Important

Because the pipeline YAML file is visible to all users with access to the repository, use these variables only for non-sensitive variables.

Internal application variables

These variables are in ${variable} format.

SQL Assurancereplaces these variables with the value of the corresponding fields. They are for internal application use only. Do not alter them.

Example

The value of the symbolic variable, ${jobCard} , is the value of the field, jobCard .

Plug-in file-based variables

These variables are in $[variable] format.

SQL Assurancereplaces these variables with the value of the corresponding variable in the plug-in variables file (default file name: AMI_DevOps.properties).

Example

The value of the symbolic variable, $[acctno] , is the value of the variable, acctno , in the plug-in variables file.

Important

  • SQL Assurance converts the $[variable] format into #variable# format and then searches for variable values in the plug-in variables file.
  • The variables provided in the samples are not keywords. You can use any variable name in the plug-in variables file and subsequently in the  config YAML file.
  • If required, you can add more symbolic variables to your config YAML file.
  • You can delete symbolic variables from the config YAML file and hard-code values. However, we do not recommend this because it prevents you from dynamically providing values for your pipeline or workflow.
  • When you create a variable for a Linux directory path, the path value requires a backslash (\) escape character before each forward slash (/) path separator (for example, Azure\/SMPE\/PropertiesFiles\/AMI_DevOps.properties.
  • When you create a variable with one of these special characters in the ($,&) value, the value requires a backslash (\) escape character before either of the special characters (for example, DB\$123, TBL\&A). This is applicable to the 'password' key-value as well.
  • Variable names of all types must be unique.
  • Do not use any property key name as a variable name (for example, SSID).
  • When you create a variable to contain one of these wildcard characters (%, *) in the value, the value requires a backslash (\) escape character before the wildcard character or double quotes around the wildcard character (for example, \%, "*"). No escape character is required if supplying a partially wildcarded value in the variable, i.e. objectName: PG% or PG*.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*