def publish_to_pulse(project, ids, data_type): jm = JobsModel(project) # Get appropriate data for data_type # using the ids provided data = [] if data_type == 'result_set': data = jm.get_result_set_list_by_ids(ids) jm.disconnect()
def publish_to_pulse(project, ids, data_type): # If we don't have a publisher (because of missing configs), then we can't # publish any pulse messages. This is okay, local installs etc. doesn't # need to publish on pulse, and requiring a pulse user is adding more # overhead to an already large development setup process. if not publisher: return jm = JobsModel(project) try: # Publish messages with new result-sets if data_type == 'result_set': # Get appropriate data for data_type # using the ids provided for entry in jm.get_result_set_list_by_ids(ids): repository = jm.refdata_model.get_repository_info(entry['repository_id']) entry['repository_url'] = repository['url'] # Don't expose these properties, they are internal, at least that's # what I think without documentation I have no clue... what any of # this is del entry['revisions'] # Not really internal, but too big del entry['repository_id'] # Set required properties entry['version'] = 1 entry['project'] = project # Property revision_hash should already be there, I suspect it is the # result-set identifier... # publish the data to pulse publisher.new_result_set( message = entry, revision_hash = entry['revision_hash'], project = project ) # Basically, I have no idea what context this runs and was inherently # unable to make kombu with or without pyamqp, etc. confirm-publish, # so we're stuck with this super ugly hack where we just close the # connection so that if the process context is destroyed then at least # messages will still get published... Well, assuming nothing goes # wrong, because we're not using confirm channels for publishing... publisher.connection.release() finally: jm.disconnect()
def publish_to_pulse(project, ids, data_type): # If we don't have a publisher (because of missing configs), then we can't # publish any pulse messages. This is okay, local installs etc. doesn't # need to publish on pulse, and requiring a pulse user is adding more # overhead to an already large development setup process. if not publisher: return jm = JobsModel(project) try: # Publish messages with new result-sets if data_type == 'result_set': # Get appropriate data for data_type # using the ids provided for entry in jm.get_result_set_list_by_ids(ids): # Don't expose these properties, they are internal, at least that's # what I think without documentation I have no clue... what any of # this is del entry['revisions'] # Not really internal, but too big del entry['repository_id'] # Set required properties entry['version'] = 1 entry['project'] = project # Property revision_hash should already be there, I suspect it is the # result-set identifier... # publish the data to pulse publisher.new_result_set( message = entry, revision_hash = entry['revision_hash'], project = project ) # Basically, I have no idea what context this runs and was inherently # unable to make kombu with or without pyamqp, etc. confirm-publish, # so we're stuck with this super ugly hack where we just close the # connection so that if the process context is destroyed then at least # messages will still get published... Well, assuming nothing goes # wrong, because we're not using confirm channels for publishing... publisher.connection.release() finally: jm.disconnect()