Trackers

Trackers are external sources of information which track some kind of item.

For example Bugzilla and OpenQA are both considered trackers by JDP. Bugzilla tracks bugs and OpenQA tracks test results. GitWeb could also be considered a tracker which tracks git commits. Some services may track a number of different items.

Design note

Hopefully new trackers can eventually be declaratively defined in conf/trackers.toml. However this is difficult when most of them seem to use different authentication methods and different data formats. So we begin with tracker specific code (e.g. trackers/Bugzilla.jl) and then try to generialise them if feasible.

Information about a tracker's API

This is a generic interface for tracker features which are simple/standard enough to configure via conf/trackers.toml. Tracker specific features are handled by Tracker specific methods dispatched on the Session type parameter

Tracker Repository

Get a single tracker from its TLA

Get a collection of all Trackers

A connection to a tracker API

Each Tracker which supports the concept of logging in should create a struct like the following

struct Session <: Tracker.AbstractSession
    # Tracker specific session data...
end

and also implement ensure_login!

Information about a Tracker's instance

Create a minimal tracker instance for an unknown tracker

Not really a session

Returns an active session

If the tracker already has an active session then return it, otherwise create one. The tracker specific modules should override this

Get an active session object for the tracker with the given TLA

Use native Julia HTTP library to access OpenQA

Unfortunately this doesn't work so well because:

1. JuliaWeb's current HTTP SSL implementation i.e. the MbedTLS wrapper
2. OpenQA's wierd authentication which is difficult to replicate outside of Perl.

A single notification preference

This can be matched against to decide whether to send a notification.

Fields

• group::JDP.Trackers.OpenQA.Link{JDP.Trackers.OpenQA.JobGroup}

  A link to the job group this preference is valid for

• user::String

  The user this preference is for

• pattern::String

  Some arbitrary pattern for matching against test properties

Makes requests to OpenQA using the official OpenQA client script

I really hate this, but we cache the data locally anyway due to the slowness of fetching from OpenQA, so the overhead of calling a Perl script can be ignored. Also see OpenQA::NativeSession's docs.

Test Sequence - A row in the diff matrix

* builds: test results for each build where a result could be found

dict = extract_toml("text... <code data-type='TOML'>[JDP.some.toml]<br> ... </code>")

Find the first instance of toml contained inside some text formatted for OpenQA job comments or group descriptions.

Only toml inside a the first code tag will be parsed. Code tags which don't have a data-type of TOML will be ignored. The <br> tags just effect the appearance in OpenQA. You should include them to make it readable.

load_notify_preferences(from::String) -> Array{JDP.Trackers.OpenQA.NotifyPref,1}

This loads and parses TOML formatted user notification preferences stored in the OpenQA job group descriptions. Each user can set one or more patterns which could be matched against test suit, test name, test flags, etc. or something else depending on the script.

Arguments

• from: This is the TLA of the tracker (e.g. "osd") where the description text should be loaded from.

OpenQA Input

The raw OpenQA job group description text should contain something like the following.

<code data-type='TOML'>
[JDP.notify.on-status-diff] <br>
rpalethorpe = ['LTP', 'OpenQA'] <br>
metan = '.' <br>
pvorel = 'LTP' <br>
</code>

For each user name you can set a single string or a vector of strings. These may then be interpreted as plain text, globs or Regexs depending on the script.

Returns

This returns a vector of NotifyPref structures. You may wish to call Functional.groupby on these to build an index.

Allows retrieving bug information from Bugzilla

Allows retrieving issue/bug information from Redmine

Send messages on Rocket Chat

Sends e-mails with the mailx command

Spammer.post_message(tracker, message::Spammer.Message)

Maybe send a broadcast/Spammer message to the e-mail list which is configured as the from address for this session. Ignores the message if it is a single line or the e-mail address is not in the mentions list.

post_message(session, to, subject, message::AbstractString)

Send an email message using the given session

Broadcast messages using multiple Trackers

Generic message body and meta data

• body: The message text. Some trackers may use the first line as the subject.
• mentions: Users or accounts to 'mention' (Rocket Chat) or CC (email). Usually this means adding something like @user to the message.

Trackers may interpret the message content differently. However each tracker should try to use the given information in a way which is analogous to the other trackers.

Send message using all trackers configured for sending broadcasts

Trackers may implement this to be included in broadcast messages