I think adding this information to the permissions files would be really nice. I'd need to update the bot for the hosting process, so just let me know what the syntax will be and I can get it place.
On Thursday, December 17, 2020 at 3:20:47 PM UTC-7 Daniel Beck wrote: > > > > On 17. Dec 2020, at 23:01, 'Gavin Mogan' via Jenkins Developers < > jenkin...@googlegroups.com> wrote: > > > > If a repo has github issues enabled, assume it uses that. > > else If the plugin name has a jira component, assume it uses that. > > else no issues link > > The beauty of the one time mass definition of issue trackers is that it > can be arbitrarily sophisticated (read: convoluted and manual), since we > don't need to re-run it once every 4 minutes on trusted.ci. > > Component name in Jira doesn't *exactly* match the plugin ID? No problem > if I can match them up in a giant table. GH issues is enabled but has 0 > total issues ever reported? Probably not relevant (and could even be > disabled). Same with Jira components that could be deleted if 0 issues > exist. But not both though. Plus we can purge Jira components without a > corresponding published plugin (I already know these exist, it's great…). > > My desire to get this right, and a lack of spare time over the last 1-2 > months has delayed this however :-/ Perhaps over the upcoming vacation. > > If others are willing to help with this, I can set something up for us to > collaborate. > > > or to daniel's point (might be on the github draft PR), do we want to > make it a hash style to support plugins that do both? Its not likely that a > plugin will want two, but during a transitory period, it might be worth > listing both > > FTR I wrote about that in > https://github.com/jenkins-infra/plugin-site-api/pull/97#discussion_r544167455 > > and > https://github.com/jenkins-infra/plugin-site-api/pull/97#issuecomment-747316256 > > -- some plugins do this deliberately. We also need to distinguish issue > tracker references for reporting new issues (one tracker is likely > preferred / enough to reference) and issue tracker references for existing > issues (probably everything with open issues should be included, or even > closed issues, depending on how it's used). > > While the vast majority of plugins will have a single tracker and that's > it, GH issues seems to become more popular as well, and since that genie's > out of the bottle by now, we should have proper support for folks wanting > to switch over. > > > As a side note, it would be super easy to use that data to also fix SCM, > so that things like the blueocean sub modules would have the right scm > links since its already part of the metadata - > https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-antisamy-markup-formatter.yml#L3 > > That's a great point. Correct; right now, update-center2 does not use RPU > metadata at all, but would need it anyway once we define the issue tracker > location there, so this should be a straightforward change on top. > > (Once we do this it's probably time to rename RPU to 'component-metadata' > or similar, and move the permissions script out of it. IIUC we already have > incrementals relying on it as well, that's what the 'github' field is for. > What blocked this so far is the terrible file format that badly needs an > overhaul as well to also better support the idea of a "plugin" > semantically. So much to do, so little time :-( ) > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/048d3dab-7389-48d5-957e-7945dbb4a7c4n%40googlegroups.com.
