Freshmaker waits for new fedmsg messages, this happens in consumer.py
. Every
fedmsg message handled by a Freshmaker is parsed by one of the parsers which can
be found in the parsers
directory. This parser converts the fedmsg to trigger
object (inherits from BaseTrigger
). All the triggers are defined in the
triggers.py
. This separation between message and trigger is done to possibly
support different messaging backends in the future or easily change the message
we react to. This trigger object is then handled by one or more handlers defined
in the handlers
directory.
The example flow for the modulemd yaml change in dist-git is following:
ModuleMetadataUpdated
trigger is
generated out of this message and the trigger event is passed to handlers.ModuleBuilt
trigger is generated and passed to
handlers.Handlers can be turned on/off in config file.
Following is the list of all available HANDLERS:
freshmaker.handlers.koji:KojiTaskStateChangeHandler
freshmaker.handlers.mbs:MBSModuleStateChangeHandler
freshmaker.handlers.git:GitRPMSpecChangeHandler
freshmaker.handlers.brew:BrewSignRPMHandler
freshmaker.handlers.git:GitDockerfileChangeHandler
freshmaker.handlers.git:GitModuleMetadataChangeHandler
freshmaker.handlers.bodhi:BodhiUpdateCompleteStableHandler
Freshmaker sends messages to either fedmsg or UMB, which depends on how it is configured, when certain event happens.
Event | Topic |
---|---|
Containers are found and will be built soon | images.found |
$ tox -e py27,py35