Send for early review on the states. Will need to update event states in all handlers.

I would add "BUILDING" here which would mean that event has been created, some artifacts has been found and it is currently being build.

Updated to:
1. Add Building state
2. Update all handlers to create the event passed to handler in db, and update the event's state accordingly.

I'm not sure it's good idea to use get_or_create_from_event in set_default_db_event_context. I would better do just get_from_event and set to None if the db_event does not exist.

For example in this handler, we don't want to create db_event for every container image build which finishes in Brew. Instead, we are only interested in finished builds of events we have created before.

When build is not found in this method, it means the Brew container build which just finished was not created by Freshmaker. I think we should not transition to NOOP in this case, but just return [].

I would suggest to rephrase it as:

A decorator which will set the db event context for the given handler, using the event passed to the handler.

Maybe it is worth including db_event in the msg as well.

To make it short and more meaningful, I guess we could use:
INITIALIZED
BUILDING
COMPLETE
FAILED
SKIPPED

@mjia , thanks for review, after discussed with @jkaluza , we agree on that creating db representation for all events can generate a lot of records in db which we don't care in most cases, so at this moment, we only do that for the manual rebuild case, I updated patch to remove the decorator, only create event in db and track its state for the manual rebuild case. I updated the EventState as you suggest.

I agree with server_default to INITIALIZED, but can we somehow set the default value for all the current records in DB to COMPELTE? Otherwise we will end up with all the historical events being marked as INITIALIZED, which is not right.

Updated patch to update state to 'COMPLETE' for historical events.

+1

:thumbsup: