The TICS GitHub action integrates the TICS code quality framework into your workflows. This allows you to effectively measure and monitor the software code quality of all your projects and their branches.

The incorporated Quality Gating feature can be used for Pull Request and Commit approvals. It can also decorate your pull request so the quality data is easily available. Furthermore, the changed files are annotated with findings from the TICS analysis, so it is clear where the issues are and thus where they need to be addressed.

There are two types of analysis modes available:

• Reference runs using TICS QServer (See section QServer). Reference points with code quality metric data are created that are used for the qualification runs. Intended for base branches of pull requests, e.g. main.
• Qualification runs using TICS Client (See section Client). Compares a set of changed files from a commit or pull request to the reference point for qualification, using a Quality Gate. Intended for pull requests and branches like feature or bug-fix branches.

• A TICS Viewer (version 2022.4 or higher) running somewhere on the network that is HTTP(S) accessible by the runner on which you want to execute the action.
• The connected runner should have Git installed.

Linux and Windows based runners, both GitHub-hosted and self-hosted, are supported.

• It is not working for forked repositories.
• It is not working for TICS installations using the legacy deployment architecture.
• macOS runners (GitHub-hosted or self-hosted) are not yet supported.

Add the TICS GitHub Action to your workflow to launch TICS code analysis and post the results of Quality Gating feature as part of your pull request. Below are some example of how to include the TICS GitHub Action step as part of your workflow.

The default mode to run is TICS Client. In this mode, the commit or pull request will be evaluated. The Quality Gate determines wether the commit or pull request qualifies for delivery. The quality gate and measurement results are reported in your action summary and optionally the pull request can be decorated.

Below is an example of the minimum configuration that needs to be created in the workflow to enable TICS Client analysis:

on: [pull_request]

jobs:
  TICS:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: TICS GitHub Action
        uses: tiobe/tics-github-action@v3
        with:
          viewerUrl: https://domain.com/tiobeweb/TICS/api/cfg?name=config
          ticsAuthToken: ${{ secrets.TICSAUTHTOKEN }}
          installTics: true

The most common use case to trigger a workflow running TICS Client is typically on pull_request. Depending on the applied way of working, other events may be also applicable. Please consult Github documentation for triggering a workflow and events that trigger workflows for more information.

The following inputs are recommended or required for this action:

viewerUrl: https://domain.com/tiobeweb/TICS/api/cfg?name=config

ticsAuthToken: ${{ secrets.TICSAUTHTOKEN }}

The following options allow to instrument TICS Client more specifically:

As of v3, the option to run TICSQServer analyses has been made available. With TICSQServer, persistent measurement points are created which are stored in your Quality Database. These measurement points are used by the TICS Client to determine how the code quality evolved from that point. TICSQServer can also compare the last obtained results with the previous run and apply Quality Gating.

on:
  push:
    branches:
      - main

jobs:
  TICS:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: TICS GitHub Action
        uses: tiobe/tics-github-action@v3
        with:
          mode: qserver
          project: project-name
          viewerUrl: https://domain.com/tiobeweb/TICS/api/cfg?name=config
          branchdir: ${{ GITHUB_WORKSPACE }}
          ticsAuthToken: ${{ secrets.TICSAUTHTOKEN }}
          installTics: true

The most common use case to trigger a workflow running TICSQServer is typically on push to main, or any other branch from which other branches are derived. Other examples are release and develop branches. Please consult Github documentation for triggering a workflow and events that trigger workflows for more information. When triggering on multiple branches, please make sure to provide the correct project or branchName value, corresponding to the TICS branch QServer will be running on.

The following inputs are recommended or required for this action:

viewerUrl: https://domain.com/tiobeweb/TICS/api/cfg?name=config

branchdir: ${{ GITHUB_WORKSPACE }}

ticsAuthToken: ${{ secrets.TICSAUTHTOKEN }}

The following options allow to instrument TICSQServer more specifically:

Below are some special parameters that can be used to control how the GitHub Action posts its results:

Below, parameters are described to control infra structure and security related aspects:

There is also the possibility to do a so called "diagnostic" run. This mode can be enabled to test if TICS has been set up properly and can run on the machine the action is run on.

on: workflow_dispatch

jobs:
  TICS:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: TICS GitHub Action
        uses: tiobe/tics-github-action@v3
        with:
          mode: diagnostic
          viewerUrl: https://domain.com/tiobeweb/TICS/api/cfg?name=config
          ticsAuthToken: ${{ secrets.TICSAUTHTOKEN }}
          installTics: true

The most common use case to trigger the diagnostic workflow is typically on workflow_dispatch. This way one can manually execute this. Please consult Github documentation for triggering a workflow and events that trigger workflows for more information.

The following inputs are recommended or required for this action:

viewerUrl: https://domain.com/tiobeweb/TICS/api/cfg?name=config

ticsAuthToken: ${{ secrets.TICSAUTHTOKEN }}

The interface (running with parameters) has been changed to better reflect its usage. This interface is now more synchronized with TICS command line usage, and has been changed to be closer to other plugins that TIOBE provides. Parameter Changes (v2/old -> v3/new):

• ticsConfiguration -> viewerUrl
• viewerUrl -> displayUrl
• projectName -> project
• branchName -> branchname
• branchDir -> branchdir
• clientData -> cdtoken
• tmpDir -> tmpdir