CIStatusAggregator

Checks continous integration endpoints to determine whether any project is being built or is broken.

The results are then saved to files that can be used by HueUpdater or TrayLamp when exposed with a web server.

Build status

AppVeyor status:

Sonarcloud status:

Motivation

I use lamps at work to give my teams instant feedback about the status of multiple projects tracked by our CI systems.

This application provides the information consumed by the programs that update those lamps. See also HueUpdater and TrayLamp.

The current version supports Jenkins endpoints only. It connects to each one and aggregates the status values.

Usage prerequisites

• Operational CI systems and related networking equipment.

• Basic JSON and Regex knowledge to edit the settings file.

• Write permission on a local folder to save the status files.

• A web server to expose the status files. Note: If you run this program on the same machine as a Jenkins controller node, you can use its /userContent directory to serve the files without having to setup a dedicated web server.

Deployment

Unpack the release file wherever you want on the target system. I suggest C:\CIStatusAggregator on Windows or /opt/CIStatusAggregator on Linux

Open the appsettings.json file with a plain text editor and carefully tweak the sample values in the CIStatusAggregator section to match your needs.

💥 NOTE
Be careful to follow JSON formatting rules, or the program will not work correctly

Here's an attempt to explain each value:

• Endpoints

  It is a list and it contains endpoint definitions. Each entry in the list defines a CI system to check and a file to write the status to.

  
  

  "CIStatusAggregator": {
    "Endpoints": [
      // endpoint definitions go in here
    ]
  }

  
  

Each endpoint definition has the following properties:

• Endpoint -> Meta -> Description

  Friendly name for the entry. Currently only used for identification in logs.

• Endpoint -> Remote -> BaseUrl

  Base URL of the CI system to check.

• Endpoint -> Remote -> JobNameFilter

  Optional section that can be used to filter the jobs that are aggregated.

• Endpoint -> Remote -> JobNameFilter -> Mode

  May be Blacklist or Whitelist.

  When Blacklist, all jobs that match the value for Regex in this section are excluded from the result.

  When Whitelist, only jobs that match the value for Regex in this section are included in the result.

• Endpoint -> Remote -> JobNameFilter -> Regex

  Regular expression that is matched against job names to act as a filter.

• Endpoint -> Local -> StatusFilePath

  Full or relative path used to write out the status for the endpoint.

  Write permission will be required to write the file, and it's usually desirable to locate the file in a folder that is shared with a web server.

  
  

  Here's an endpoint definition that ONLY checks the jobs that contain the word build in their name and saves the outcome to the file status/build.json.

  
  

  {
    "Meta": {
      "Description": "Build jobs"
    },
    "Remote": {
      "BaseUrl": "https://jenkins.example",
      "JobNameFilter": {
        "Mode": "Whitelist"
        "Regex": "build",
      }
    },
    "Local": {
      "StatusFilePath": "status/build.json"
    }
  }

  
  

  Here's an endpoint definition that checks all the jobs that DO NOT contain the word build in their name and saves the outcome to the file status/deploy.json.

  
  

  {
    "Meta": {
      "Description": "Deployment jobs"
    },
    "Remote": {
      "BaseUrl": "https://jenkins.example",
      "JobNameFilter": {
        "Mode": "Blacklist"
        "Regex": "build",
      }
    },
    "Local": {
      "StatusFilePath": "status/deploy.json"
    }
  }

  
  

Finally, use your preferred scheduling method to run this application frequently. I usually run it every minute with the Windows Task Scheduler or with a systemd timer.

License

This project is licensed under the MIT License - see the LICENSE.md file for details