If Syns2Jira fails, who gets alerted. This PR aims to fix that by looking up the admins (through the default JIRA instance) and sends them an email with the full traceback when Sync2Jira fails!
Take everything in this except block and move it to its own function called report_failure or something so that this main function can remain high level with no low-level details.
report_failure
main
Also, at the end of the except block, include a bare raise statement which will re-raise the exception so it gets printed in the logs and kills the process with a non-zero exit code.
except
raise
rebased onto bef4c974c8ad74c79b1d68754a2c04f1e3f46b0a
Could this be:
message = ' No owner could be found for username %s' % issue.downstream.get('owner') log.warning(message.strip()) raise ValueError(message)
... so that the reason propagates to the error email?
I don't see where issue gets assigned here. Some error in refactoring?
issue
I also don't see where admin_template gets used below here. Perhaps it isn't needed?
admin_template
If it isn't needed, perhaps you can dispense with the whole setup here to query Jira to find more info about the admins in the first place. You could just keep the list of admins in the config as a list of emails, and email them directly. It would be much more simple code in this error case.
What would happen if sync2jira failed in the inner loop because there was suddenly some problem trying to access jira itself. The email code here would fail as well, and we wouldn't be notified.
Better to streamline this function. WDYT?
rebased onto 7948851f17e9c474bd5ef5113bf81bb59f97ef75
Could this be: message = ' No owner could be found for username %s' % issue.downstream.get('owner') log.warning(message.strip()) raise ValueError(message) ... so that the reason propagates to the error email?
Could this be: message = ' No owner could be found for username %s' % issue.downstream.get('owner') log.warning(message.strip()) raise ValueError(message)
Yes, I like this better.
Yeah needs to be removed.
I also don't see where admin_template gets used below here. Perhaps it isn't needed? If it isn't needed, perhaps you can dispense with the whole setup here to query Jira to find more info about the admins in the first place. You could just keep the list of admins in the config as a list of emails, and email them directly. It would be much more simple code in this error case. What would happen if sync2jira failed in the inner loop because there was suddenly some problem trying to access jira itself. The email code here would fail as well, and we wouldn't be notified. Better to streamline this function. WDYT?
I agree its easier. But I wanted to keep it so that when we create the duplicate email we can have the admins names so they're easier to get in touch with. Maybe have both (username + email), that way we can just use email for when we are sending the failure notice? Take a look at the most recent PR and let me know what you think.
Looks better, but this whole section with jira_instance and client can probably be removed too?
jira_instance
client
rebased onto 5e8b5dbbf7cc10a237d66397867dfa6f71109217
Yup my mistake. @ralph final check?
Thanks! :+1:
rebased onto 064bff8b1d356276030fbd134e2128025870a268
Pull-Request has been merged by sidpremkumar
If Syns2Jira fails, who gets alerted. This PR aims to fix that by looking up the admins (through the default JIRA instance) and sends them an email with the full traceback when Sync2Jira fails!