Category: CI/CD

APIF-Auto, a command line tool that supports automated API Fortress test execution, is the ideal tool for executing tests in an Azure DevOps workflow.   

The pipeline script below serves as a template for creating a step in your Azure DevOps Pipeline for testing your APIs with API Fortress. If you’d like to take a look at the documentation for APIF-Auto, click here.

It’s important to note that this is an example of an Azure DevOps Pipeline. Experienced users are free to configure their workflow as best suits their needs.

trigger:
- master
jobs:
- job: 'apif'
  pool:
    vmImage: 'ubuntu-latest'
  strategy:
    matrix:
      Python37:
        python.version: '3.7'
    
  steps:
  - script: |
      python -m pip install --upgrade pip
      python -m pip install -r requirements.txt
    displayName: 'Install dependencies'

  - script: |
      python apif-run.py run-all security -S -f junit -o results/TEST-junit.xml
    displayName: 'Run APIF Tests'

  - task: PublishTestResults@2
    inputs:
      testRestultFiles: 'result/junit.xml'
      testRunTitle: 'APIF Test Results'
    condition: succeededOrFailed()

First, it’s worth mentioning that in this example we have the APIF-Auto files in our Azure DevOps repository. Let’s break down what’s happening in the script above:

• First, we are defining the OS image we would like to use as the testing environment. In our case we chose the latest Ubuntu which has support for the latest Python version.
• Next, in the same scope we are defining which version of Python we will be using for the test (Apif-Auto is a Python script)
• Then, in the part labeled “steps” there are a few things happening:
  • In the first section labeled “script” we are installing “pip,” and then installing the dependencies from our “requirements.txt” file
  • In the second section labeled “script” we are running “apif-run.py” to execute all of the tests in our project called “security”
  • Finally, there is a section labeled “task,” this is where we are evaluating the outputted results from the “apif-run” execution. 

APIF-Auto, a command line tool that supports automated API Fortress test execution is an ideal tool for executing API Fortress tests in a Jenkins workflow.   
The pipeline script below serves as a template for creating stages in your Jenkins Pipeline for testing your APIs with API Fortress’ tests that are stored in Github. If you’d like to take a look at the documentation for APIF-Auto, click here.

It’s important to note that this is an example of a Jenkins Pipeline. Experienced Jenkins users are free to configure their workflow as best suits their needs.

node {
   def mvnHome
   stage('Preparation') {
      git 'https://github.com/theirish81/temp.git'
   }
   stage('Build') {
      
   }
   stage('API Fortress'){
       sh 'python /var/jenkins_home/apif-auto/apif-push.py jenkins_project -r -p testing/apifortress'
       sh 'mkdir -p target/apifortress'
       sh 'python /var/jenkins_home/apif-auto/apif-run.py run-all jenkins_project -S -f junit -o target/apifortress/junit.xml'
   }
   stage('Results') {
      junit '**/target/apifortress/junit.xml'
   }
}

Let’s break down what’s happening in the script above:

• First, we have the “Preparation” stage, this is where we will define the Github repository where we have the tests stored. 
• Next, we have the “API Fortress” stage, where a few things are happening:
  • sh 'python /var/jenkins_home/apif-auto/apif-push.py jenkins_project -r -p testing/apifortress' This is the command that will pull the tests from the Github repository we defined in the first step and push them into the API Fortress project “jenkins_project” using the apif-push.py tool.
  • sh 'mkdir -p target/apifortress' This is the command that will create a directory to store the results from our API Fortress test executions. Remember the -p flag! It’ll keep the pipeline from overwriting the directory if it already exists in the future.
  • sh 'python /var/jenkins_home/apif-auto/apif-run.py run-all jenkins_project -S -f junit -o target/apifortress/junit.xml' This is the command that will execute all the tests we pushed into the “jenkins_project” using the apif-run.py tool and store the returned junit test results into the directory we created in the previous step. 
• Finally, we have the “Results” stage, where we evaluate the junit results to see if the test passed or failed.

1. Directly
2. Through a CI/CD Platform

Direct Integration with Micro Focus ALM

Using a CI/CD Platform

• APIF-Auto – Preferred Method
• API Fortress and CI/CD (General)

• APIF-Auto and Jenkins
• API Fortress and Jenkins
• API Fortress and Bamboo

APIF-Auto, a command line tool that supports automated API Fortress test execution is an ideal tool for executing API Fortress tests in a Jenkins workflow.

The pipeline script below serves as a template for creating a stage in your Jenkins Pipeline for testing your APIs with API Fortress. If you’d like to take a look at the documentation for APIF-Auto, click here. It’s important to note that this is an example of a Jenkins Pipeline. Experienced Jenkins users are free to configure their workflow as best suits their needs.

pipeline{
   agent any
stages {
   stage('Execute API Fortress Tests') {
     steps {
       sh 'mkdir -p apifortress-reports'
       sh 'python /Path/to/apif-Auto/directory/apif-run.py run-all demo -S -f junit -o apifortress-reports/apif.xml'
       }
   post {
     always {
       junit "apifortress-reports/"
       }
     }
   }
  }
}

• • First, remember the -p flag! It’ll keep the pipeline from overwriting the directory if it already exists in the future.

• Second, remember the name! We’re going to need it later.

• Executing API Fortress tests from a CI/CD tool
• Incorporating API Fortress tests in a Git version control plan.
• Pushing test code from an IDE to the API Fortress platform.

APIF-RUN

RUN EXECUTION FLAGS

• run-all – RUN ALL – This will execute all of the tests in a chosen project.
• run-by-tag – RUN BY TAG – This will execute all tests with a selected tag (requires the -t flag to set tag)
• run-by-id – RUN BY ID – This will execute a test with a specific ID (requires the -i flag to set id)
• hook – HOOK – This is the webhook of the project you are working with. This can be either an API Fortress URL, or the key from a configuration file (set the path to the config file with the -c tag)

RUN OPTION FLAGS

• -S – SYNC – This will provide a response body with the result of the test.
• -f – FORMAT – This will determine the format of the test result output (JSON, JUnit, Bool). REQUIRES SYNC MODE (-S)
• -d – DRY – This will cause the test run to be a dry run.
• -s – SILENT – This will cause the test to run in silent mode.
• -o – OUTPUT – This will write the result of the test to a local file. You must provide the path to the file to be created. Remember your filetype! (.json/.xml)
• -c – CONFIG – This provides the path to a configuration file which can provide webhooks and user credentials. If no path is specified, the program will look for a config.yml in the same directory as it is (./config.yml)
• -C – CREDENTIALS – This allows you to manually pass user credentials (username:password) (SUPERSEDES CONFIG FILE)
• -t – TAG – This is how you pass a tag for RUN BY TAG mode.
• -i – ID – This is how you pass an ID for RUN BY ID mode.
• -e – ENVIRONMENT – This is how you pass environmental/override variables. The format is key:value. You can pass multiple sets of environmental variables like so: key:value key1:value1 key2:value2

APIF-PUSH

PUSH EXECUTION FLAGS

• hook – HOOK – This is the webhook of the project you are working with. This can be either an API Fortress URL, or the key from a configuration file (set the path to the config file with the -c tag)

PUSH OPTION FLAGS

• -p – PATH – This provides the path to the test file you wish to upload. You can pass multiple paths.
• -r – RECURSIVE – This flag will make the call recursive; It will dive through the directory passed with -p and grab every test in all of its subdirectories.
• -b – BRANCH – This allows you to specify a Git branch that these test files are attached to. Default is master.
• -c – CONFIG – This provides the path to a configuration file which can provide webhooks and user credentials. If no path is specified, the program will look for a config.yml in the same directory as it is (./config.yml)
• -C – CREDENTIALS – This allows you to manually pass user credentials (username:password) (SUPERSEDES CONFIG FILE)
• –T – TAG – This allows you to pass tags to be appended to the test after it is pushed. This will OVERWRITE ANY EXISTING TAGS. Multiple tags can be passed.
• -t – ADD TAG – This will allow you to add additional tags to a test that already has tags attached.

CONFIGURATION FILE

hooks:
  - key: cool_proj1
    url: https://mastiff.apifortress.com/app/api/rest/v3/A_WEBHOOK
    credentials:
      username: (your username)
      password: (your password)
  - key: uncool_proj
    url: https://mastiff.apifortress.com/app/api/rest/v3/ANOTHER_WEBHOOK
    credentials:
      username: (another username)
      password: (another password)
  - key: unauth_proj
    url: https://mastiff.apifortress.com/app/api/rest/v3/JUST_A_WEBHOOK_WITHOUT_CREDENTIALS
test_directory: /tests

EXAMPLES

NOTES

• The order of the optional arguments passed does not matter.
• Remember, in a bash environment, anything that has a space in it needs to be wrapped in quotes. This goes for paths, filenames, etc.

POST-RECEIVE SCRIPT FOR GIT

Step 1 – Install Jenkins HTTP Plugin

Step 2 – Generate an API Hook

Step 3 – Execute HTTP Call from Jenkins