My current role is more of a DevOps role and I’m spending more time than usual monitoring and administrating various services, such as the GitLab instance we use for source control, build pipelines, issue management, etc. While the GitLab UI is very useful for certain kinds of tasks the rich RESTful API allows you to easily build your own custom tools to to monitor, analyse, and investigate the things you’re particularly interested in.
For example one of the first views I wanted was an alphabetical list of all runners with their current status so that I could quickly see if any had gone AWOL during the night. The alphabetical sorting requirement is not something the standard UI view provides hence I needed to use the REST API or hope that someone had already done something similar first.
GitLab Clients
I quickly found two candidates: python-gitlab and go-gitlab-client which looked promising but they only really wrap the API – I’d still need to do some heavy lifting myself and understand what the GitLab API does. Given how simple the examples were, even with curl, it felt like I wasn’t really saving myself anything at this point, e.g.
curl --header "PRIVATE-TOKEN: $token" "https://gitlab.example.com/api/v4/runners"
So I decided to go with a wrapper script [1] approach instead and find a way to prettify the JSON output so that the script encapsulated a shell one-liner that would request the data and format the output in a simple table. Here is the kind of JSON the GitLab API would return for the list of runners:
[
{
"id": 6,
"status": "online"
. . .
}
,
{
"id": 8,
"status": "offline"
. . .
}
]
JQ – The JSON Tool
I’d come across the excellent JQ tool for querying JSON payloads many years ago so that was my first thought for at least simplifying the JSON payloads to the fields I was interested in. However on further reading I found it could do some simple formatting too. At first I thought the compact output using the –c option was what I needed (perhaps along with some tr magic to strip the punctuation), e.g.
$ echo '[{"id":1, "status":"online"}]' |\
jq -c
[{"id":1,"status":"online"}]
but later I discovered the –r option provided raw output which formatted the values as simple text and removed all the JSON punctuation, e.g.
$ echo '[{"id":1, "status":"online"}]' |\
jq -r '( .[] | "\(.id) \(.status)" )'
1 online
Naturally my first thought for the column headings was to use a couple of echo statements before the curl pipeline but I also discovered that you can mix-and match string literals with the output from the incoming JSON stream, e.g.
$ echo '[{"id":1, "status":"online"}]' |\
jq -r '"ID Status",
"-- ------",
( .[] | "\(.id) \(.status)" )'
ID Status
-- ------
1 online
This way the headings were only output if the command succeeded.
Neater Tables with Column
While these crude tables were readable and simple enough for further processing with grep and awk they were still pretty unsightly when the values of a column were too varied in length such as a branch name or description field. Putting them on the right hand side kind of worked but I wondered if I could create fixed width fields ala printf via jq.
At this point I stumbled across the StackOverflow question How to format a JSON string as a table using jq? where one of the later answers mentioned a command line tool called “column” which takes rows of text values and arranges them as columns of similar width by adjusting the spacing between elements.
This almost worked except for the fact that some fields had spaces in their input and column would treat them by default as separate elements. A simple change of field separator from a space to a tab meant that I could have my cake and eat it, e.g.
$ echo '[ {"id":1, "status":"online"},
{"id":2, "status":"offline"} ]' |\
jq -r '"ID\tStatus",
"--\t-------",
( .[] | "\(.id)\t\(.status)" )' |\
column -t -s $'\t'
ID Status
-- -------
1 online
2 offline
Sorting and Limiting
While many of the views I was happy to order by ID, which is often the default for the API, or in the case of jobs and pipelines was a proxy for “start time”, there were cases where I needed to control the sorting. For example we used the runner description to store the hostname (or host + container name) so it made sense to order by that, e.g.
jq 'sort_by(.description|ascii_downcase)'
For the runner’s jobs the job ID ordering wasn’t that useful as the IDs were allocated up front but the job might start much later if it’s a latter part of the pipeline so I chose to order by the job start time instead with descending order so the most recent jobs were listed first, e.g.
jq ‘sort_by(.started_at) | reverse’
One other final trick that proved useful occasionally when there was no limiting in the API was to do it with jq instead, e.g
jq "sort_by(.name) | [limit($max; .[])]"
[1] See my 2013 article “In The Toolbox – Wrapper Scripts” for more about this common technique of simplifying tools.
