search

spacetelescope / jirahub

A package for syncing JIRA tickets and Github issues
http://jirahub.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
14 stars 8 forks source link

Consider changing design for Heroku deployment #19

Open pllim opened 5 years ago

pllim commented 5 years ago

Currently, your documentation says, "Need a list of issues to watch and are linked together – if not, all opened issues should be tracked." I don't think this is compatible with Heroku deployment workflow; please correct me if I am wrong.

Have you considered changing how this works so that it can be deployed in an automated fashion? For example, see baldrick and astropy-bot from the Astropy project, or any number of bots deployed for other big projects out there (CPython, matplotlib, etc).

eslavich commented 5 years ago

The refactored bot doesn't use a list of issues, but it does need persistent storage for one thing -- the placeholder timestamp that tells it where to start looking for updated issues. It can run without that, but it's pretty time-consuming to iterate over every issue in large projects.

Maybe the bot should be able to store its placeholder in S3? Or maybe in JIRA somewhere, though AFAIK JIRA doesn't support project-level custom fields.

pllim commented 5 years ago

If it listens to events via webhook, it does not need to comb through the whole repo every time (though maybe it does on that very first run but that is a one-time setup overhead). On an event, it only needs to worry about the issue/PR sending that event, and then still has to comb through the comments but typical issue/PR has less than 100 comments, so should not be too bad. Still occasionally susceptible to race condition though.

The point I am trying to make is that I don't think persistent storage is necessary on the bot side, unless I miss something that JIRA needs. My bot experience is purely GitHub thus far.

eslavich commented 5 years ago

Oh, I see. You're right, JIRA also has a webhooks feature. Webhook events are easy to lose though, in the past I've always made sure back them up by crawling through updates in a scheduled job. But it could be that I was just using flaky services.

pllim commented 5 years ago

Webhook events are easy to lose though

While I agree that sometimes webhooks go MIA, in my experience on GitHub, they work most of the time. Even scheduled crons are at the mercy of internet latency. So no solution is 100% perfect.

stscijgbot commented 5 years ago

Tracked on JIRA as issue SCSB-17.