Tag Koji build with correct tag which is triggered by message bus
Project description
# Message Tagging Service
![](https://img.shields.io/pypi/v/message-tagging-service.svg?label=PyPI)
![](https://img.shields.io/pypi/pyversions/message-tagging-service.svg?label=Python)
![](https://img.shields.io/pypi/l/message-tagging-service.svg?colorB=green&label=License)
[![Build Status](https://travis-ci.org/fedora-modularity/message-tagging-service.svg?branch=master)](https://travis-ci.org/fedora-modularity/message-tagging-service)
Message tagging service is a microservice to tag build with proper tags, which
is triggered by specific message from a message bus. Currently, service
supports to tag module build according to a module build state change event.
This service works with Python 3.6 and 3.7.
## Workflow
This is the service workflow, for example of a module build.
- Listen on message bus (that is fedmsg in Fedora) and waiting for module build
state change event. Only ``ready`` state is handled.
- Service consult to predefined rule definitions to check if that module build
matches any rule.
- If one or more rules are matched, tag the module build with tags defined in
matched rules.
- Send message to message bus to announce a module build is tagged with
specific tags.
## Rule Definition
Rule definition is documented in a [Modularity document](https://pagure.io/modularity/blob/master/f/drafts/module-tagging-service/format.md).
For detailed information of how the rules are matched, please refer to [paragraph](https://pagure.io/modularity/blob/master/f/drafts/module-tagging-service/format.md?text=True#_8) in that document.
## Configuration
There are two type of configurations.
- ``fedmsg.d/``: including config files for fedmsg hub. ``config.py`` configures
fedmsg hub for service itself. ``mts.py`` enables defined consumer and
configures to connect UMB accordingly.
- ``mts_config.py``: including configs for service. There are two sections,
``BaseConfiguration`` provides default options which could be reused for
running in production. ``DevConfiguration`` contains anything for running in
development mode.
## Messaging
Once tags are applied to a build successfully, a message will be sent to topic
``build.tagged`` on message bus. Message has this format:
```
{
"build": {
"id": id,
"name": name,
"stream": stream,
"version": version,
"context": context,
},
"nvr": N-V-R,
"destination_tags": [tag1, tag2, ...]
}
```
Different message bus has different topic prefix to construct the full topic
name. For Fedora, a full topic name could be
``org.fedoraproject.prod.mts.build.tagged``. For internal UMB, it could be
``VirtualTopic.eng.mts.build.tagged``.
## Enviornment Variables
### MTS_DRY_RUN
Dry run mode. Currently, no build is tagged actually in dry run mode. No
particular is required. Just define ``MTS_DRY_RUN`` in environment variables.
### MTS_DEV
Switch service to run in development mode as long as ``MTS_DEV`` is defined.
### MTS_RH
Make service run with internal infrastructure. No particular value is required.
Just define ``MTS_RH`` in environment variables.
### MTS_STOMP_URI
A comma-separated string of UMB broker URIs. For example:
```
'messaging-broker01.dev1.redhat.com,messaging-broker02.dev2.redhat.com'
```
### MTS_STOMP_CRT
An absolute path to certificate file.
### MTS_STOMP_KEY
An absolute path to private key file.
Both of the certificate file and this private key file are required to connect
to internal UMB brokers.
## Contribution
Report issue at https://github.com/fedora-modularity/message-tagging-service/issues.
Before making a pull request, ensure the changes do not break anything and are
covered by tests. Run tests:
```
tox
```
# Chagne Logs
# 0.1 (2019-01-21)
- First release that MTS is able to handle specific message to tag build.
![](https://img.shields.io/pypi/v/message-tagging-service.svg?label=PyPI)
![](https://img.shields.io/pypi/pyversions/message-tagging-service.svg?label=Python)
![](https://img.shields.io/pypi/l/message-tagging-service.svg?colorB=green&label=License)
[![Build Status](https://travis-ci.org/fedora-modularity/message-tagging-service.svg?branch=master)](https://travis-ci.org/fedora-modularity/message-tagging-service)
Message tagging service is a microservice to tag build with proper tags, which
is triggered by specific message from a message bus. Currently, service
supports to tag module build according to a module build state change event.
This service works with Python 3.6 and 3.7.
## Workflow
This is the service workflow, for example of a module build.
- Listen on message bus (that is fedmsg in Fedora) and waiting for module build
state change event. Only ``ready`` state is handled.
- Service consult to predefined rule definitions to check if that module build
matches any rule.
- If one or more rules are matched, tag the module build with tags defined in
matched rules.
- Send message to message bus to announce a module build is tagged with
specific tags.
## Rule Definition
Rule definition is documented in a [Modularity document](https://pagure.io/modularity/blob/master/f/drafts/module-tagging-service/format.md).
For detailed information of how the rules are matched, please refer to [paragraph](https://pagure.io/modularity/blob/master/f/drafts/module-tagging-service/format.md?text=True#_8) in that document.
## Configuration
There are two type of configurations.
- ``fedmsg.d/``: including config files for fedmsg hub. ``config.py`` configures
fedmsg hub for service itself. ``mts.py`` enables defined consumer and
configures to connect UMB accordingly.
- ``mts_config.py``: including configs for service. There are two sections,
``BaseConfiguration`` provides default options which could be reused for
running in production. ``DevConfiguration`` contains anything for running in
development mode.
## Messaging
Once tags are applied to a build successfully, a message will be sent to topic
``build.tagged`` on message bus. Message has this format:
```
{
"build": {
"id": id,
"name": name,
"stream": stream,
"version": version,
"context": context,
},
"nvr": N-V-R,
"destination_tags": [tag1, tag2, ...]
}
```
Different message bus has different topic prefix to construct the full topic
name. For Fedora, a full topic name could be
``org.fedoraproject.prod.mts.build.tagged``. For internal UMB, it could be
``VirtualTopic.eng.mts.build.tagged``.
## Enviornment Variables
### MTS_DRY_RUN
Dry run mode. Currently, no build is tagged actually in dry run mode. No
particular is required. Just define ``MTS_DRY_RUN`` in environment variables.
### MTS_DEV
Switch service to run in development mode as long as ``MTS_DEV`` is defined.
### MTS_RH
Make service run with internal infrastructure. No particular value is required.
Just define ``MTS_RH`` in environment variables.
### MTS_STOMP_URI
A comma-separated string of UMB broker URIs. For example:
```
'messaging-broker01.dev1.redhat.com,messaging-broker02.dev2.redhat.com'
```
### MTS_STOMP_CRT
An absolute path to certificate file.
### MTS_STOMP_KEY
An absolute path to private key file.
Both of the certificate file and this private key file are required to connect
to internal UMB brokers.
## Contribution
Report issue at https://github.com/fedora-modularity/message-tagging-service/issues.
Before making a pull request, ensure the changes do not break anything and are
covered by tests. Run tests:
```
tox
```
# Chagne Logs
# 0.1 (2019-01-21)
- First release that MTS is able to handle specific message to tag build.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Close
Hashes for message-tagging-service-0.1.tar.gz
Algorithm | Hash digest | |
---|---|---|
SHA256 | 7b8cd218307acd45a40e3c41dd73d2ec9715411e788607c8738e2c9896eb1261 |
|
MD5 | 4ab3f2d8482211b9c4f4d69dddda7ce6 |
|
BLAKE2b-256 | 09349e100b5484ac0f3059abe8def988d6a2fd8b3e6b86a067c7ac350dedc2e8 |