new jira type trackers #608
Conversation
jsvob
force-pushed
the
new_jira_type_tracker_wip_tmp_notes
branch
from
66cff9a
to
13445b6
Compare
jsvob
force-pushed
the
new_jira_type_tracker_wip_tmp_notes
branch
2 times, most recently
from
c0f6fbd
to
9e29bde
Compare
jsvob
force-pushed
the
new_jira_type_tracker_wip_tmp_notes
branch
2 times, most recently
from
4eadde8
to
b43453d
Compare
jsvob
changed the title
|
@RedHatProductSecurity/osidb-devs Please pre-review if you have spare cycles on Thursday Aug 22 or Monday Aug 26. OSIDB-2980 contains a comment with a link to a relevant slack thread. Next week I will rebase it to modern version of master, will create the appropriate file in ps-constants and try to write a few smoke tests. My intention is to have it merged after Aug 26 and write the rest of the tests in parallel so that it can be tested with a few brave projects, while the rest stays with the old and tested Bug issuetype (if that's not OK, please provide adequate reasoning so that delay reasons are clear for management). Thank you! |
|
Reviewing commit-by-commit is probably more pleasant than the whole diff. |
|
@RedHatProductSecurity/osidb-devs Ready for re-review with two caveats: The code that fetches jira_bug_issuetype.yml doesn't work yet for some reason and I yet have to test the two fields marked with |
|
The two methods marked with @RedHatProductSecurity/osidb-devs please review |
|
I'll squash and rebase before merge, so that I don't make it even more confusing by changing history. |
|
The two methods marked with |
osidb/models.py
Outdated
| @@ -3501,6 +3501,18 @@ class SpecialConsiderationPackage(models.Model): | |||
| name = models.CharField(max_length=255, unique=True) | |||
|
|
|||
|
|
|||
| class JiraBugIssuetype(models.Model): | |||
There was a problem hiding this comment.
Not a big deal but I think that logically this should rather belong to
https://github.com/RedHatProductSecurity/osidb/blob/master/apps/trackers/models.py
There was a problem hiding this comment.
Moved in a new commit. I'll fix the commit & migration history mess during squash and rebase.
| name=self.affects.first().ps_module | ||
| ).bts_key | ||
| ).exists(): | ||
| actual_jira_issuetype = "Bug" |
There was a problem hiding this comment.
One thing to be careful about is that before the first PS constants collection after the release we are actually not going to default to the old behavior but to the new one. We could overcome it by checking whether there is actually at least some JiraBugIssuetype but that might that cause problems when all of them adapt and the field gets empty. Otherwise we could manually do the sync in console right after the release or do it eg. inside a migration.
There was a problem hiding this comment.
How would we make it behave sanely once the last project switches to Vulnerability issuetype? If we add a check here and now, then in that distant (?) point in future, it will trigger confusing and already-forgotten behavior of switching all new trackers back to Bug. Maybe I'm missing something.
Doing the first sync manually sounds good to me.
There was a problem hiding this comment.
Yeah, I am OK with it too. Just keep it in mind before we go to production and we should be ready to just hit a command and run it as I think for the PS constants last time it was quite laborious.
Prepares for "new" Vulnerability issuetype-based TrackerJiraQueryBuilder. Related to OSIDB-2980
Prepares for "new" Vulnerability issuetype-based TrackerJiraQueryBuilder. Related to OSIDB-2980
Prepares for "new" Vulnerability issuetype-based TrackerJiraQueryBuilder. Related to OSIDB-2980
Add switching between "new" Vulnerability issuetype and "old" Bug issuetype using ps-constants. Related to OSIDB-2980
even on debug-disabled deployments. This is important because we expect to encounter bugs in Jira configuration when creating trackers. Related to OSIDB-2980
jsvob
force-pushed
the
new_jira_type_tracker_wip_tmp_notes
branch
from
29fd912
to
18ab156
Compare
Related to OSIDB-2980