Here is a proposed roadmap for Gabbi (issue assignee to adjust as desired):
HTTParty's get call and Feedjira's parse call should be separated out into their own dedicated methods. Each of the new dedicated methods should incorporate their own error handling now that we have a pattern for doing so
move the core code out into its own repository
for now the CI part can stay in the main repo to leverage tokens/credentials as needed until those can be replicated elsewhere
publish the code as a Rubygem
lead the dev team in a brainstorming session - including but not limited to existing backlogged issues - to produce a TODO task list for the bot that can live in the bot's repo
Things to consider:
Implement error handling and possibly retry logic for each operation that could fail
Add newrelic_rpm to the project!
On sleep(1) - We sleep even if there is only 1 notification going out for today and even if it has been more than a second since the last message was sent out. This one requires a bit more architecting to fix, and can easily be tabled given the positive benefits previously mentioned.
The need to go with a class variable has demonstrated that we should refactor the notifiers to use an instance of SlackNotifier and have SlackNotifier's current static/class methods become dynamic/instance methods.
Currently the model prevents us from running both notifiers at the same time, because they will share an errors array. That's enough of an indication to move to instance methods and an instance variable, @errors.
workato-integration[bot]
commented
2 years ago
Here is a proposed roadmap for Gabbi (issue assignee to adjust as desired):
Things to consider:
Implement error handling and possibly retry logic for each operation that could fail
Add
newrelic_rpmto the project!On
sleep(1)- We sleep even if there is only 1 notification going out for today and even if it has been more than a second since the last message was sent out. This one requires a bit more architecting to fix, and can easily be tabled given the positive benefits previously mentioned.The need to go with a class variable has demonstrated that we should refactor the notifiers to use an instance of SlackNotifier and have SlackNotifier's current static/class methods become dynamic/instance methods.
Currently the model prevents us from running both notifiers at the same time, because they will share an errors array. That's enough of an indication to move to instance methods and an instance variable, @errors.