> On 17. Dec 2020, at 23:01, 'Gavin Mogan' via Jenkins Developers
> <[email protected]> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/8F06DF58-7DFD-4C10-BD6F-8E6FFC0738A5%40beckweb.net.
