quick WIP branch: https://pagure.io/fedora-qa/blockerbugs/commits/feature/close_issue_inactive_milestone

The original idea was (@kparal correct me if I'm wrong), that you shouldn't be looking directly to Pagure repo and use Blockerbugs app as entrypoint, this also applies to #115 .

Here is the staging BBA instance:
http://blockerbugs-blockerbugs.apps.os.fedorainfracloud.org/milestone/32/final/buglist

This is discussed in #115, the same arguments apply here.

Now that F33 release is coming to an end, I think this is a feature worthy of our attention. But I'd like to re-define this ticket to be related to inactive releases, not milestones. It is quite frequent to bump nominations from Beta to Final, and therefore if we start closing Beta-related tickets (once Beta is GO), we'll have to deal with re-opening them if somebody moves the nomination to Final. That's error-prone work. However, if we only implement this for releases, it should be pretty safe. The reason is that for each release, we create a separate ticket, intentionally. So even if we close all F33-related tickets, and somebody bumps the nomination to F34, that will create a new ticket anyway, and we don't need to worry about re-using older tickets.

So I propose to:
1. Implement code to close all tickets related to an inactive release (meaning no milestone is active for that release).
2. Either implement a new command that we'll run manually on the server after a release is GO (and it's removed from BBA), or make it happen automatically with each sync. I'm currently on a fence between these two, running it manually is of course safer, and it's not that much extra work twice per year, but at the same time make it automatic is of course convenient. Thoughts? (I'd personally probably rather start with manual execution).

The new code should add a comment to this ticket, for example:

Release F33 is no longer tracked by BlockerBugs, closing this ticket.

and close the ticket.

@lbrabec Are you willing to take this? Your previous branch is still available. Thanks a lot.

I don't see any option in cli to set release inactive, I presume it is done in the admin interface (by @adamwill ?).

In the admin UI, I can see that the only active milestones are 34-beta and 34-final, but active releases are 33 and 34. The code for closing issues is going to be quite simple, but it will rely on the person, that is currently setting milestones inactive, to set releases inactive as well.

That's fine, I think. We can even add some reasonable command output, like:

$ blockerbugs close-inactive-discussions
Looking for discussion tickets belonging to inactive releases (i.e. excluding currently active: f34, f35)...
Closing f33 ticket https://pagure.io/fedora-qa/blocker-review/issue/123
Closing f33 ticket https://pagure.io/fedora-qa/blocker-review/issue/124
...

If the expected tickets don't get closed, you can look at the output and immediately understand the problem:

$ blockerbugs close-inactive-discussions
Looking for discussion tickets belonging to inactive releases (i.e. excluding currently active: f33, f34, f35)...
No inactive discussion tickets found.

Hey @lbrabec , any update here? Thanks.

@lbrabec yeah, I update the blockerbugs milestones manually. It sucks. I keep meaning to roll it into the updatetrackers script. Even better would be to have a bot to do it automatically, based on the release JSON...

@lbrabec yeah, I update the blockerbugs milestones manually. It sucks. I keep meaning to roll it into the updatetrackers script. Even better would be to have a bot to do it automatically, based on the release JSON...

what do you think if oraculum handled that out for blockerbugs? It's currently not fetching all the data we need for new milestone/release creation but that'd be pretty easy thing to do. It'll then expose all the information needed on an endpoint and blockerbugs would just look there once upon a time and create new releases/milestones accordingly.

Here is the code currently processing blocker trackers: https://pagure.io/fedora-qa/oraculum/blob/master/f/oraculum/utils/bugzilla.py#_30 , I can add there everything what's needed without too much trouble. It'll also be possible for oraculum to handle trackers creation in the future, if we wanted.

I think we'll have the "official" deployment figured out soon ( https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/6SOKJSYDP65TVPQ4XAXFZKXDBQHUUVRO/ ).

I update the blockerbugs milestones manually. It sucks.

Can you create a new issue please? Perhaps we can implement it in BBA directly, perhaps you can create a bot, perhaps @frantisekz can do it in oraculum. Either way, let's have it in a separate discussion and trackable, thanks!

Roger, will do.

@lbrabec Hi, any progress here? We should really test and implement this before we have too many F34 tickets created.

Which reminds me, can you please implement a --dryrun option? Just to be safe when testing this. Thanks!

I updated branch feature/close_issue_inactive_milestone. I'll do some testing and create PR ASAP.

A PR is in #165

Commit b712bcc fixes this issue

The code is deployed and all F33-related discussion tickets have been closed. Yay.