would be great so one doesn't have to forward to the {dev,community}/pureos channels
Description
Event Timeline
Is this a Tracker <--> Matrix channel? We already have #dev/pureos-changes so you don't mean that channel I assume.
gitlab would be nice too but likely fine grained (e.g. calls -> calls channel, phosh/phoc/squeekboard -> phosh channel) - we had a bug for that somewhere in gitlab iirc, the above is about the pureos tracker only.
Phabricator's API is called conduit. I can pull data from conduit and it looks like this;
{
"id": "1001", "phid": "PHID-TASK-4lpwd5rgworwzdwkbdg7", "authorPHID": "PHID-USER-kcngpcgit2gapkthvlnm", "ownerPHID": null, "ccPHIDs": [ "PHID-USER-kcngpcgit2gapkthvlnm" ], "status": "open", "statusName": "Open", "isClosed": false, "priority": "Needs Triage", "priorityColor": "violet", "title": "amber: postgresql-common securit update blocked due to downstream changes", "description": "As far as i can tell amber is lacking these security updates due to downstream changes in popstgresql-common:\n\nhttps://lists.debian.org/debian-security-announce/2019/msg00220.html\n\nSee https://master.pureos.net/synchrotron/\n```\npostgresql-common \tbuster/updates amber-security \t200+deb10u3 \t200pureos1 \tRequires manual merge of downstream changes with source. \n```", "projectPHIDs": [], "uri": "http://tracker.pureos.net/T1001", "auxiliary": [], "objectName": "T1001", "dateCreated": "1613384648", "dateModified": "1613384648", "dependsOnTaskPHIDs": []
}
The id, status, title and description look suitable for dumping into a Matrix channel. Is that okay @guido or are you looking for something more?
https://github.com/lkhq/laniakea/tree/master/src/mirk is the tool we use to push to Matrix.
Architecturally this should actually be implemented in such a way that a bugtracker change emits a new message on Laniakea's ZeroMQ-based message-bus, and that message is then picked up by the Matrix bot and relayed to the channel
that way, other consumers can pick up the messages as well and act on them for other purposes than showing a channel message (that's how automatic bug closing was implemented in the past, actually)
(but "in the past" means deep in the past where Trac was used for bugtracking)
The messages Laniakea sends are multipart-ZeroMQ messages with a header/subject in rDNS form, like _lk.archive.new-package and a JSON body with a few standardized fields and one freeform "data" part. The JSON part is signed with an Ed25519 signature from the messaging relay, so messages can be authenticated as correct
(message submission happens via a Curve25519-encrypted connection to a relay, from where they are distributed to interested parties)
and yes, this should absolutely be documented properly ;-)
Fortunately, the Laniakea Python module has helpers for this stuff so you don't have to touch it directly - in theory all this needs is a consumer of bug tracker events that submits them to the relay, and then the Matrix bot only needs to be told how to convert the messages into human-readable form
Code to send events is basically just:
emitter = EventEmitter(LkModule.TESTSUITE) data = {'test': 'blahblah'} emitter.submit_event('event-subject', data)
All provided the crypto secrets are present