GitHub issues option in HOSTING

250 views
Skip to first unread message

Tim Jacomb

unread,
Feb 2, 2020, 6:14:14 AM2/2/20
to Jenkins Developers

Hi


GitHub issues use is growing in the ecosystem, many plugins are now using it,


Some benefits from my experience in using it:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.


Some repositories that are using them:

https://github.com/jenkinsci/configuration-as-code-plugin, https://github.com/jenkinsci/slack-plugin

https://github.com/jenkinsci/google-compute-engine-plugin

And many more...


I’ve heard that this was raised a year ago or so, and there were two reasons that it wasn’t adopted:

  • Delete issues support - for security fixes, GitHub now supports this

  • Transferring issues - now supported, but I think you need write access, may need a bot to ease this, but we can see how this goes.

  • Cross repository / component work - There’s now organisation level projects that can be used to group and track issues across projects https://github.com/orgs/jenkinsci/projects/3 (Plugin docs), https://github.com/orgs/jenkinsci/projects/1  (Community Bridge: Jenkins Configuration-as-Code developer tools), this doesn’t solve the issue of a bug in multiple components, there’s a few ways this could be solved, one issue for tracking it, tagging the maintainers teams in the issue, reporting it multiple times and linking the issues together (possibly the best option?).


I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.


Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.


I would also suggest that we add some text to the Component field that says:

‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.


Any feedback or questions?


Thanks

Tim


Oleg Nenashev

unread,
Feb 2, 2020, 8:29:30 AM2/2/20
to Jenkins Developers
As discussed at the contributor summit, I am totally in favor of opening the GitHub issues a bit more, and maybe even making it default for new plugins. Thanks Tim for starting thus thread!

Regarding the implementation, my proposal would be to firstly add explicit issue tracker links on the plugin site. Maven metadata already supports it, we just need to expose it in the update center.

Then we could, for example, keep components and use a Jira bot when an issue is misreported.

Just removing a component will have limited impact, because many components are often not reported to a right component anyway (triage is needed, or users just report it wrongly). Removing components is likely to encourage people to take another random component or _unsorted

Ullrich Hafner

unread,
Feb 2, 2020, 9:10:33 AM2/2/20
to Jenkins Developers
I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location (i.e., GitHub) we should also enforce (well at least work towards) a unique landing page for issues from our users. Otherwise users are confused where to report issues, where to look for existing issues etc. 

Also it makes inter-project communication for developers more complicated. Very often issues are not only related to one component, and currently it is quite easy to ping the component lead of the other component or to reassign to a different component, etc. For instance, some time ago I reported an incompatibility of a Jenkins plugin with the JCasC plugin: it was very cumbersome to check if I should use GitHub or Jira to report the issue. 

What might make sense to discuss is, if we should replace Jira with GitHub issues for all projects? I doubt that GitHub issues are already a replacement for such a sophisticated tool like Jira, but maybe other developers see that differently. 

On the other hand, maybe we can improve our existing development process so that the missing peaces from your requirements get integrated into Jira:

  • Easy subscription to issues / pull requests for repositories I maintain / co-maintain

This is quite easy in Jira as well.

  • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

I think I don’t get the point here, maybe you need to clarify why Jira is here more complex

  • Tight integration with SCM, issues are closed when a pull request is merged, and you can click on a commit to see what version it was released in, JIRA on the other hand is very out of sync.
  
We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task. 

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicygmVEFYSemjj5eLNSW5usfuK3v4MmCotWfbbgNSZ2RA%40mail.gmail.com.

Joseph P

unread,
Feb 2, 2020, 10:34:20 AM2/2/20
to Jenkins Developers
As a maintainer I find it very difficult that I have to use Jira for inter project work.

- Question what username you have on Jira not always the same
- find Jira searching very bothersome compared to some of the logical either code searches or be it issue searches.
  - Tim and I have been very thankful to be able to search across JenkinsCI org on github.
     Here is a good example of inter project communication: https://github.com/jenkinsci/bom/pull/172

- do not find components very useful.
  - Have to ask to be made default assignee
    - That means going to IRC and poking people 👻
  - I might miss someone because only one can be assigned and people do not use watchers.
    - find it a lot easier to look in the pom.xml or see commit history and ping those who might know something on github.
  - Getting these dreaded emails that just keep pilling up in our inbox 😰.
    - Prefer github that allows you to subscribe and unsubscribe and their web notifications JUST WORKS and even better with the new Notification beta.
  - often forget in Jira on the components that might interest me.
  - You have to be a JQL wizard to find anything again! 🧙‍♂️

- Jira is slow compared to GitHub.

- Jira integration is just bad compared to what you can get from interlinking issues and pull requests on GitHub.

- Jenkins already has a bad situation of too many systems to handle messaging and source configuration management. Case in point being this mailing list 😅
  - Would be awesome to simplify on a single chat platform and a single SCM.

Again finding something again in Jenkins means I have to look either into mailing lists, Jira, confluence, IRC, gitter, slack or GitHub.
Perhaps I missed something.

Would be great if we could boil it down to two 🤯

For crying out loud I had to ask on GitHub where to find this body of work: https://github.com/jenkinsci/configuration-as-code-plugin/pull/1264#issuecomment-581144871

To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

Chris Kilding

unread,
Feb 3, 2020, 8:06:12 AM2/3/20
to jenkin...@googlegroups.com
I'm inclined to agree with Joseph and Tim.

When maintaining my plugin I often wonder how many bug reports I'm losing because users either:

- Can't find their way through our bug tracking system (and all the labels and categories that a bug must be annotated with), compared to GH Issues which is very simple.
- Get discouraged from reporting a bug because they're more annoyed by making yet another online account / username + password.

Occasionally, users have reported their bugs in comments on active GitHub PRs where wholly different bugs are being worked on, as this is the only way they've been able to reach out within the GitHub ecosystem, and it's still lower friction than Jira.

My plugin is a leaf node in the plugin ecosystem, i.e. it is an implementation of a Jenkins API with no further code dependents. Possibly as a result, issues that have been reported tend not to reach beyond the plugin itself in scope, and I've never seen an issue that was incorrectly reported (and needed to be transferred). This category of plugins would be ideal to move to GH issues as a first step.

Chris
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Tim Jacomb

unread,
Feb 7, 2020, 4:34:01 AM2/7/20
to Jenkins Developers
Any other opinions?

So far we have 3 +1, and 1 -1

This isn't asking that we move everything over, but make it easier for new plugin maintainers to use GitHub issues.

Thanks
Tim

Olblak

unread,
Feb 7, 2020, 8:50:13 AM2/7/20
to Jenkins Developers ML
Maintaining issues.jenkins-ci.org is time-consuming, and it's hard to find someone who wants to do it.
While I totally agree that we shouldn't use multiple ticket system, I don't see real good solution he
re

We migrate from Jira to Jira Cloud
-> We keep the history
-> No maintenance
-> There is a GitHub Jira <> integration
-> Mobile app support

We migrate from Jira to Github Issues
-> We lose the ticket's history
-> No maintenance
-> We can use our GitHub account
-> Everything in one place
-> Github issues is a common workflow compared to other OSS projects
-> Github issues can't be used for security or any other private issues
-> We can configure GitHub with https://github.com/probot/settings

-> Not really in favor of that, for all the reasons mention here, more we have a hard deadline in September to upgrade wiki.jenkins-ci.org

I am also considering GitHub issues for the infra project even if GitHub issues is not an option for security issues

Remark: Atlassian has a nice sponsoring program so as far as I remember we can use everything for free

So to answer the question, I would be in favor to experiment using GitHub issues for the hosting project with one project at the organization level for cross repository work

---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---

Jesse Glick

unread,
Feb 7, 2020, 9:06:30 AM2/7/20
to Jenkins Dev
On Fri, Feb 7, 2020 at 8:50 AM Olblak <m...@olblak.com> wrote:
> We migrate from Jira to Jira Cloud
> We migrate from Jira to Github Issues

Can we migrate to Jira Cloud with history intact, _and_ encourage use
of GitHub issues for new components?

Slide

unread,
Feb 7, 2020, 9:32:08 AM2/7/20
to Jenkins Developer List
For maintaining history, I've done something similar in the past when migrating a project from codeplex to GitHub. The script I had migrated the comments and the attachments as best it could. I could try a proof of concept of people are interested.

--
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-de...@googlegroups.com.

James Nord

unread,
Feb 7, 2020, 9:56:20 AM2/7/20
to Jenkins Developers
I generally agree with Ulli's comments.

so far we are all talking about the developer experience when interacting with issues. we need to also think of the user experience to Jenkins users too. it kills me every time I need to file an issue and try and work out where it is to be reported and I consider myself knowledgeable about Jenkins and it's plugins.

Olblak

unread,
Feb 7, 2020, 11:48:23 AM2/7/20
to Jenkins Developers ML
Technically we could migrate all issues to github, at least I saw some python scripts doing that. I would be more concerned by the security issues, so indeed we could also have both tools in place where most of the things are on github issues

---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---

> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/61d3f5f3-106c-4bf5-a032-33b59be2f23b%40googlegroups.com.
>

Daniel Beck

unread,
Feb 7, 2020, 12:53:47 PM2/7/20
to Jenkins Dev


> On 2. Feb 2020, at 12:13, Tim Jacomb <timja...@gmail.com> wrote:
>
> • Much easier to be a co-maintainer, with JIRA only the ‘component lead’ gets notified by default, you _can_ create your own filters and subscriptions, but it’s a lot more effort and most people (including me) don’t do that.

At least you have the option to. I use several Jira dashboards optimized for various tasks, and dread having to replace them with bookmarks to gitHub.com/issues

> I think it makes sense to offer an option during the hosting process on which issue tracker the maintainer wants to use.
>
> Currently maintainers are able to enable GitHub issues themselves after the repo is hosted but that leaves them with a JIRA component that users who are used to Jenkins JIRA might report issues into.

This seems reasonable. If they don't want a component in Jira, they don't get one.

>
> I would also suggest that we add some text to the Component field that says:
> ‘Many components use GitHub issues now, if you can’t find the component create an issue on component’s GitHub repository.

"Cool, where do I find that?"

Daniel Beck

unread,
Feb 7, 2020, 1:02:15 PM2/7/20
to Jenkins Dev


> On 2. Feb 2020, at 15:10, Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> I don’t think that this is a good idea to support two different issue tracker landing pages. As we encourage every body to host everything in *one* location … it was very cumbersome to check if I should use GitHub or Jira to report the issue. … replace Jira with GitHub issues for all projects?

Many years ago we didn't really allow GitHub issues (no admin permissions before GitHub allowed disabling destructive actions). Everything was in Jira. Then people wanted to use GH issues, despite some objections, including mine, that this will be pretty hostile to users. Now some popular plugins use GH issues, and suddenly everyone is supposed to migrate, because having two systems is bad? Maybe maintainers should have considered that before they clicked "[x] Enable issue tracker" despite having a Jira component…

FWIW a recent proposal would add a link to the appropriate issue tracker to the plugin metadata, which can be exposed in the plugin site and/or Jenkins directly. That would take care of the "where to report" problem.


> We had that in Jira as well. The service was located on Kohsuke’s server is now not running anymore. I think it would be awesome if we could restore that integration. Maybe we can use the existing Jira Jenkins plugin for that task.

We had it for a while, but it used too many API calls and went above the allowed API quota. There should be threads on the infra list. Maybe it's better now?

Daniel Beck

unread,
Feb 7, 2020, 1:04:26 PM2/7/20
to Jenkins Dev


> On 7. Feb 2020, at 15:56, James Nord <james...@gmail.com> wrote:
>
> it kills me every time I need to file an issue and try and work out where it is to be reported and I consider myself knowledgeable about Jenkins and it's plugins.

I mentioned it in a previous response, but here's the link: https://github.com/jenkins-infra/update-center2/pull/331

This has the potential to make this easier than ever before.

Gavin Mogan

unread,
Feb 7, 2020, 1:31:35 PM2/7/20
to jenkin...@googlegroups.com
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

I think the big push in the past for jira was because you couldn't migrate issues between repos before in github. That got changed.. though you still need write permission in both repos, so regular users can't migrate issues - https://help.github.com/en/github/managing-your-work-on-github/transferring-an-issue-to-another-repository - so its better, but not great. Most users are randomly guessing what components to assign things to, often just using the auto complete. For example, https://issues.jenkins-ci.org/browse/JENKINS-44148 I added the core component because after digging around on the pipeline steps doc, I learned that archiveArtifact is a "core" step. Though now that I think about it, it probably means the basic pipeline steps. Its really hard to figure out which component/repo pipeline issues should go into.

With github I can "watch" the entire repo, so new PRs and new issues get emailed to me. Doesn't matter if i'm the maintainer (single or multiple), or just a random user trying to help out.

With jira, I'm either auto assigned the issue due to whatever component was first picked, or nothing at all. Groups of maintainers can't be notified. Un-assigned tickets don't get notified. I like many others don't want to assign it to me until I'm working on it, so someone else could take it if they wanted.
I will say the cloud model of jira is super easy to make plugins for now, and I bet if we could reach out to https://marketplace.atlassian.com/apps/1213851/watch-it-for-jira-cloud?hosting=cloud&tab=overview to get some sort of open source deal.

So far no solution is great for me, I'm a slight preference for github (but maybe jira cloud if auto watching can be handled), but I agree fully that consistency is good. I never really look at jira as it stands right now its such a huge mess.

Gavin

--
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-de...@googlegroups.com.

James Nord

unread,
Feb 7, 2020, 8:35:04 PM2/7/20
to Jenkins Developers
>With jira, I'm either auto assigned the issue due to whatever component was first picked, or nothing at all. Groups of maintainers can't be notified. Un-assigned tickets don't get notified

create a filter that matches things you want to be notified for.
subscribe to that filter in https://issues.jenkins-ci.org/secure/ManageFilters.jspa

Gavin Mogan

unread,
Feb 8, 2020, 2:06:53 AM2/8/20
to jenkin...@googlegroups.com
Oh cool, I didn't know about that feature.

--
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-de...@googlegroups.com.

Daniel Beck

unread,
Feb 8, 2020, 7:13:57 AM2/8/20
to JenkinsCI Developers
On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

When was the last time our Jira instance had performance/availability problems? I don't think there have been any problems so far this year, and probably not to a notable degree in the last few months of last year...

Tim Jacomb

unread,
Feb 8, 2020, 8:46:30 AM2/8/20
to Jenkins Developers
(replies inline)
 Now?
image.png
It takes me 9 seconds to open JIRA for it to be interactive.
And then I have to log in every single time...

Compared to GitHub issues which is:
image.png
~3 seconds to be fully done, but I can interact with the page after 2 seconds.
And I'm already logged in so I don't need to spend another 15 seconds logging in.

I've definitely clicked to open a JIRA issue before and then not distracted while it was loading...

Thanks
Tim

--
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-de...@googlegroups.com.

Daniel Beck

unread,
Feb 8, 2020, 9:14:33 AM2/8/20
to JenkinsCI Developers
On Sat, Feb 8, 2020 at 2:46 PM Tim Jacomb <timja...@gmail.com> wrote:
(replies inline)
On Sat, 8 Feb 2020 at 12:13, Daniel Beck <db...@cloudbees.com> wrote:

On Fri, Feb 7, 2020 at 7:31 PM 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
I also really want to see issues.jenkins go away, but mostly due to how slow it is. I don't think cloud is a lot better, but way less maintenance for people.

When was the last time our Jira instance had performance/availability problems? I don't think there have been any problems so far this year, and probably not to a notable degree in the last few months of last year...


 Now?
image.png
It takes me 9 seconds to open JIRA for it to be interactive.
And then I have to log in every single time...

The only view that even comes close to that for me is the System Default dashboard when not logged in, is that what I'm seeing here?(How about following an issue link from the changelog?)

I have five custom dashboards, so I never see the default one -- and opening issues is almost instantaneous for me. Otherwise I'd go crazy, updating dozens of issues every week for the past several years.

I'm also not logged out more than once a week or so. Is it possible that you're rarely using Jira to begin with?

Chris Kilding

unread,
Feb 8, 2020, 6:54:22 PM2/8/20
to jenkin...@googlegroups.com
While there are differences of opinion on the issue *storage* problem (ie do we store our issues in Jira or GitHub), there seems to be common ground on solving the *access* problem for users that report issues.

If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.

I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

This suggests a couple of questions:

1. Can such a GitHub connector be installed on the Jira we’ve already got?
2. If not, can anyone provide a (vague) timescale for getting things into Jira Cloud and enabling the connector? (I appreciate this is probably a long job.)

Chris
--
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-de...@googlegroups.com.

Tim Jacomb

unread,
Feb 9, 2020, 3:19:41 AM2/9/20
to jenkin...@googlegroups.com
As far as I know for jira cloud the only log in options are atlassian account or SAML (may be premium option, can’t find docs for it)


Daniel Beck

unread,
Feb 9, 2020, 12:24:35 PM2/9/20
to Jenkins Dev


> On 9. Feb 2020, at 00:53, Chris Kilding <chris+...@chriskilding.com> wrote:
>
> there seems to be common ground on solving the *access* problem for users that report issues.
>
> If we can get a GitHub connector up and running for Jira, so that any user who wants to report an issue can simply sign in with the GitHub account that they (in all likelihood) have already got, we can solve the access problem and lower the barrier to entry for reporters.
>
> I don’t know the split between how many reporters we lose because they can’t (or won’t) make a Jira account vs. how many we lose because they can’t navigate Jira once they’re in. But it would be a start.

So far I've never felt like we needed more bugs reported, or features requested. We collectively suck at responding and fixing anyway. What's the point of making it easier to have one's issue ignored?

(To be clear: This is not a good situation. But it seems we should fix _that_ first.)

Also, I haven't seen any proof so far for the assumption that everyone has a GitHub account anyway. That seems like a very OSS developer centric view of the world.

Olblak

unread,
Feb 10, 2020, 3:51:20 AM2/10/20
to Jenkins Developers ML
Let's bring back the infrastructure point of view into the discussion

Jira to Jira Cloud INFRA-2010
If someone is willing to do more experimentation with it, be my guest but for what I understand contributors require an Atlassian account to connect on Jira cloud
so no GitHub SSO, neither LDAP auth and max 5000 users, which also means regular old accounts and spammers cleanup.
For the context, today we have 104626 accounts on Jira
-> In the current state, because of the identity management, I am not very optimistic about migrating all projects to Jira cloud, 

Remaining on issues.jenkins-ci.orb, [INFRA-2262], 
No integration between Jira and Github as it uses Github API and we hit the limit very quickly so we had to disable it
The second element, excepted Tyler and me, nobody "maintains" it and unfortunately, we can only accept trusted people to work on issues.jenkins-ci.org as it contains the security work.
so I don't see how we can keep maintaining it unless we have someone dedicated to Jira who upgrade Jira every several weeks and also work on performance
-> In the current state, because of the maintaining effort, I am seriously not optimistic to stay on issues.jenkins-ci.org

Moving to GitHub issues
Identity management and maintaining effort is solved, but some extra work is needed to migrate Jira tickets to Github issues. 
And personally I am a bit concerned about managing the all Jenkins project on GitHub for multiple reasons but they are largely compensated by not having to maintain a ticketing system. I also think that another concern that I have is because I am not as experienced as I am with Jira which is why I am willing to give it a try for a small project like the hosting project. but if we do that, we need to be clear on an end date for the experimentation.

Maybe someone has another proposition like neither Github or Jira

Cheers


---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---

> -- 
> 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 
> To view this discussion on the web visit 

Ullrich Hafner

unread,
Feb 10, 2020, 4:08:17 AM2/10/20
to Jenkins Developers

Am 10.02.2020 um 09:50 schrieb Olblak <m...@olblak.com>:

Let's bring back the infrastructure point of view into the discussion

Jira to Jira Cloud INFRA-2010
If someone is willing to do more experimentation with it, be my guest but for what I understand contributors require an Atlassian account to connect on Jira cloud
so no GitHub SSO, neither LDAP auth and max 5000 users, which also means regular old accounts and spammers cleanup.
For the context, today we have 104626 accounts on Jira
-> In the current state, because of the identity management, I am not very optimistic about migrating all projects to Jira cloud, 


Do we still need our LDAP if we migrate Jira to the cloud? What other services are using our LDAP? (Can ci.jenkins use GitHub Authentication?)

Daniel Beck

unread,
Feb 10, 2020, 4:12:06 AM2/10/20
to Jenkins Dev


> On 10. Feb 2020, at 09:50, Olblak <m...@olblak.com> wrote:
>
> The second element, excepted Tyler and me, nobody "maintains" it and unfortunately, we can only accept trusted people to work on issues.jenkins-ci.org as it contains the security work.

Any option that removes issues.j.o entirely will need to have a plan that includes a complete and tamper-proof mapping of every plugin maintainer's Jenkins/Artifactory account to the future issue tracker account, including all past maintainers.

Right now, I assign issues to whoever is listed in permission YAML files. How would this work in the future?

Daniel Beck

unread,
Feb 10, 2020, 4:15:09 AM2/10/20
to Jenkins Dev


> On 10. Feb 2020, at 10:08, Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> What other services are using our LDAP?

Account app (duh), Wiki (sort of going away very slowly), all our Jenkins instances (ci, trusted.ci, and cert.ci), and Artifactory (this is why you use your Jenkins user name in https://github.com/jenkins-infra/repository-permissions-updater/ )

Could we exclude LDAP from this thread? It's already a mess, we went from "Wouldn't it be nice if we had better support for GH issues in the hosting process" to "Let's shut down Jira".

Olblak

unread,
Feb 10, 2020, 4:42:26 AM2/10/20
to Jenkins Developers ML
What other services are using our LDAP?

They are so many places where we use ldap that we won't get rid of it easily, especially in the infra part, and I am really not concerned about it, as it's really easy to maintain

---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---

> -- 
> 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 
> To view this discussion on the web visit 

Ullrich Hafner

unread,
Feb 10, 2020, 5:28:17 AM2/10/20
to jenkin...@googlegroups.com
Ok, then let us summarize the side track:
We cannot and do not want to drop Jira because it is used in a lot of places and the features are superior to GitHub issues. We can improve performance and usability of Jira if we would deploy a more recent version of Jira (or use the cloud version).

Then I am more then before -1 on opening support for GitHub issues, since our users should simply use only one tool to report issues for Jenkins and its plugins. (And for me as developer it makes cross-component issue handling also simpler if there is only one tool to use.)
> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/37A68695-188E-499A-A7AB-F9604673E4F4%40beckweb.net.

Tim Jacomb

unread,
Feb 10, 2020, 7:34:29 AM2/10/20
to jenkin...@googlegroups.com
Who is going to update it? And what benefit does that bring?

And moving to the cloud version brings less features, a new account type everyone has to sign up to, but less maintenance

Daniel Beck

unread,
Feb 10, 2020, 8:44:00 AM2/10/20
to Jenkins Dev


> On 2. Feb 2020, at 12:13, Tim Jacomb <timja...@gmail.com> wrote:
>
> GitHub issues use is growing in the ecosystem, many plugins are now using it,

Given the discussion, I now seriously doubt that this would be beneficial over the long-term to the project.

Not because the proposal is a bad idea on its own (it's not), but based on the answers so far, it looks to me like some want Jira gone completely, and want to use this proposal as a back door to get rid of issues.j.o without an adequate replacement in the name of "unifying" where issues are tracked. This isn't even perhaps an individual contributor's position, but between "I want GH issues / I don't want Jira" and "Multiple issue trackers are bad", this is where we seem to be heading.

If we go with this approach and similar ones (for example the better plugin metadata that allows having an issue tracker link directly in Jenkins plugin manager), we need to be committed to continue having different issue trackers for a while. Making it easier for users who maintainers want to use GH issues shouldn't mean we'll ignore others' preference for Jira.

And if Jira presents significant challenges e.g. to the infra team, which it looks like, I'd be happy to have a separate, open discussion about the continued use of Jira. I resist not because I love it so much (I don't), but because I use it a lot and I simply don't see how my use cases translate elsewhere (GH issues and to a degree Jira Cloud) -- some of which are pretty core to my role as security officer (for example the case from my email from yesterday). But that conversation should be based on a properly defined IEP/JEP looking at all aspects of such a transition, rather than a disjointed set of messages across several channels/threads.

Gavin Mogan

unread,
Feb 10, 2020, 7:57:09 PM2/10/20
to jenkin...@googlegroups.com
I'll freely admit I dislike jira, but I think the mix for plugins of using jira and github are very confusing.

I see a major issue, that security issues can't really work in github, since they can't be made private for certain people, which means if you'd have issues for a plugin in both github and jira its a big mess. And I believe only github org admins (or at least someone with write support in both repos) can move issues between repos. Which will make issues getting lost due to the wrong component even worse.

I'm all in favor of non core and non plugins using github to make things more visible, but not for the central project.

And infra has a lot more secrets, so it makes sense to be in jira where things can be managed.

I'm totally in favor of moving to cloud jira instead of hosted jira to reduce maintenance, but that requires a lot of work too.



--
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-de...@googlegroups.com.

Tim Jacomb

unread,
Feb 11, 2020, 2:11:28 AM2/11/20
to jenkin...@googlegroups.com
I feel like we can work something out for the security project, possibly there’s a better tool for it...

I don’t think it’ll work easily in the cloud version either

For transferring you need at least write and possibly admin on both ends to use the GitHub ui for it, but there’s a GitHub app for it that looks like it would do what we need: 

Not sure how infra having secrets makes it a better fit for jira?

Olblak

unread,
Feb 14, 2020, 7:30:35 AM2/14/20
to Jenkins Developers ML
I am happy that we start this discussion early enough before the current Jira version becomes at the end of life.
It's a topic important enough to have as much feedback as possible but also whatever we decide we won't have support from 100% of the contributors otherwise we wouldn't have this long thread.

Whatever we decide, I think we should try to apply the same process for all the tickets.

If someone is interested to help to work on a JEP to summarize all the pros/cons here and identify possible solutions, that would be awesome and then I suggest that once done, we organize a vote using the Condorcet tool.


---
gpg --keyserver keys.gnupg.net --recv-key 52210D3D
---


Daniel Beck

unread,
Feb 14, 2020, 9:17:57 AM2/14/20
to Jenkins Dev


> On 11. Feb 2020, at 08:11, Tim Jacomb <timja...@gmail.com> wrote:
>
> I feel like we can work something out for the security project, possibly there’s a better tool for it...
>
> I don’t think it’ll work easily in the cloud version either

Since it seems like we've managed to finally really derail this thread, I'll follow up:

The major obstacle as I see it is the mapping of users. This applies to every alternative not backed by our LDAP.

We need something that every maintainer inherently has access to, ideally even used before; and a tamper-proof & complete mapping between those accounts and the accounts in permission YAML files (which we use as reference to determine who even is a maintainer) that does not require any actions by hundreds of current maintainers.

Right now, we get all of this for free: LDAP account creation creates Jira account; plugin hosting requests and most plugins' issues are tracked in Jira; both systems share the same user name.

We already have trouble with some Jira accounts having outdated notification email addresses in Jira, and need to go some lengths to contact these maintainers, and doing it via email typically means I am then the SPOF for any direct email responses. Doing something similar for every issue simply won't scale.

Jesse Glick

unread,
Feb 14, 2020, 10:59:22 AM2/14/20
to Jenkins Dev
Since the thread is indeed pretty well derailed by now,

On Fri, Feb 14, 2020 at 9:17 AM Daniel Beck <m...@beckweb.net> wrote:
> The major obstacle as I see it is the mapping of users. This applies to every alternative not backed by our LDAP.

Right. It would be great to switch to GitHub SSO, avoiding the
confusion between oleg-nenashev vs. oleg_nenashev and so on, and
ending a bunch of issues such as old email aliases. JIRA and
Artifactory would need to support this connector. (So few people have
special permissions on ci.jenkins.io that this seems like a minor
issue.) “Mapping” would boil down to ensuring that any active
maintainers have gone to https://accounts.jenkins.io/myself/ to set
their GitHub ID prior to the switchover.

Daniel Beck

unread,
Feb 15, 2020, 8:07:53 AM2/15/20
to JenkinsCI Developers
On Fri, Feb 14, 2020 at 4:59 PM Jesse Glick <jgl...@cloudbees.com> wrote:

Right. It would be great to switch to GitHub SSO, avoiding the
confusion between oleg-nenashev vs. oleg_nenashev and so on, and
ending a bunch of issues such as old email aliases. JIRA and
Artifactory would need to support this connector. (So few people have
special permissions on ci.jenkins.io that this seems like a minor
issue.) “Mapping” would boil down to ensuring that any active
maintainers have gone to https://accounts.jenkins.io/myself/ to set
their GitHub ID prior to the switchover.

That is neither complete (as it requires user action), nor a tamper-proof (AFAIR, nothing ensures you're not lying, or even have a typo).

We regularly contact maintainers who haven't released anything in more than a year or two about security issues. So this mapping would _at least_ have to be enforced 1-2 years before we switch over to a Jira alternative.

Radek Antoniuk

unread,
Mar 25, 2020, 12:27:05 PM3/25/20
to Jenkins Developers
I would like to vote +1 for GitHub Issues. 

I tried migration via the API for jira plugin and the only thing that we would lose is the original reporter (it would be noted in the comment but not the issue creator) - I think that this can be lived with.
See https://github.com/warden/jira-plugin/issues for examples (those were all automated via API).

With the fact that we're not using fixVersion field and release process/board in JIRA (I don't think we need it TBH), I think that GH Issues would be more than enough.
Additionally:
- we could use GH Actions for automated label management, releases etc...
- the users to use GH SSO only and not create special account in Jenkins
- we lose performance problems with JIRA infra
- we have a single and _automated_ code-to-issue linking on code-level even

 

Tim Jacomb

unread,
Mar 26, 2020, 3:42:37 AM3/26/20
to Jenkins Developers
That's cool Radek, was this what you used to migrate them? https://github.com/parcelLab/jira-to-github

Or something else?

--
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-de...@googlegroups.com.

Radosław Antoniuk

unread,
Mar 26, 2020, 6:28:00 AM3/26/20
to jenkin...@googlegroups.com

Gavin Mogan

unread,
Jun 9, 2020, 7:24:34 PM6/9/20
to Jenkins Developers
So re surfacing this old topic now that we've merged and deployed the updated plugin site with GitHub releases and jira issues 

My next steps is start supporting GitHub issues for plugins that uses them. But this topic never came to a conclusion.

If we are officially supporting GitHub issues, then I think the only remaining issue is how to move incorrectly files issues. I think you need triage or write access to migrate an issue, so I'd like to see a bot that has access to move to either a) everyone b) everyone with write access to Jenkins org or c) with write to either source or destination repo.

My vote is b.

I'd like a final conclusion and an "official response" before I clean up the PRs for update center and plugin site API.


On Thu., Mar. 26, 2020, 3:28 a.m. Radosław Antoniuk, <radek.a...@gmail.com> wrote:
--
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-de...@googlegroups.com.

Ullrich Hafner

unread,
Jun 10, 2020, 4:14:06 AM6/10/20
to Jenkins Developers

Am 10.06.2020 um 01:24 schrieb 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com>:

So re surfacing this old topic now that we've merged and deployed the updated plugin site with GitHub releases and jira issues 


Seems that I overlooked the PR for the new plugins site. Nice work, thanks for that! 


My next steps is start supporting GitHub issues for plugins that uses them. But this topic never came to a conclusion.

If we are officially supporting GitHub issues,

I think this has not been decided yet...

then I think the only remaining issue is how to move incorrectly files issues. I think you need triage or write access to migrate an issue, so I'd like to see a bot that has access to move to either a) everyone b) everyone with write access to Jenkins org or c) with write to either source or destination repo.

My vote is b.


I’m not sure if I can follow: you want to have a bot that syncs Jira and GitHub? Or is it a one-way from Jira to GitHub?

I'd like a final conclusion and an "official response" before I clean up the PRs for update center and plugin site API.


On Thu., Mar. 26, 2020, 3:28 a.m. Radosław Antoniuk, <radek.a...@gmail.com> wrote:
I used this one: https://github.com/warden/jira-issues-importer

--
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-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPe2pWjopjvpX%2B_oRKZ%2BW6PCsDaJj5NpUtRnj-YdJGY0t1zrdg%40mail.gmail.com.

--
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-de...@googlegroups.com.

Gavin Mogan

unread,
Jun 10, 2020, 4:20:49 AM6/10/20
to Jenkins Developers
Yea I want to get the discussion restarted so a conclusion can happen.

And no, was just thinking of transferring tickets between plugins that do GitHub issues. And the triaging issues within, but yea that's another issue with the mixed env

Radosław Antoniuk

unread,
Jun 10, 2020, 5:47:48 AM6/10/20
to jenkin...@googlegroups.com
Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).
The question is how to prevent opening new issues in Jira afterwards, but this actually could be automated via a simple JQL looking for open issues in Jira that would be auto-closed with a message: "please report on plugin's github issues".

Slide

unread,
Jun 10, 2020, 9:46:53 AM6/10/20
to Jenkins Developer List
We could remove the component from Kira for the plugin. It wouldn't stop someone from opening one and assigning it to the wrong component, but people assign to the wrong component all the time anyway.

On Wed, Jun 10, 2020, 02:47 Radosław Antoniuk <radek.a...@gmail.com> wrote:
Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).
The question is how to prevent opening new issues in Jira afterwards, but this actually could be automated via a simple JQL looking for open issues in Jira that would be auto-closed with a message: "please report on plugin's github issues".

--
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-de...@googlegroups.com.

Radosław Antoniuk

unread,
Jun 10, 2020, 9:50:35 AM6/10/20
to jenkin...@googlegroups.com
On Wed, Jun 10, 2020 at 3:46 PM Slide <slide...@gmail.com> wrote:
We could remove the component from Kira for the plugin. It wouldn't stop someone from opening one and assigning it to the wrong component, but people assign to the wrong component all the time anyway.

Yes, removing the category is the other option I thought about, +1 on this as the simplest way to proceed.
Note the downside however that removing the category would remove it from all the existing old issues as well.
 

Ullrich Hafner

unread,
Jun 10, 2020, 9:56:43 AM6/10/20
to Jenkins Developers
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <radek.a...@gmail.com>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


The question is how to prevent opening new issues in Jira afterwards, but this actually could be automated via a simple JQL looking for open issues in Jira that would be auto-closed with a message: "please report on plugin's github issues".


--
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-de...@googlegroups.com.

Radosław Antoniuk

unread,
Jun 10, 2020, 10:05:52 AM6/10/20
to jenkin...@googlegroups.com
Am 10.06.2020 um 11:47 schrieb Radosław Antoniuk <radek.a...@gmail.com>:

Not sure I got the question right, but IMO it's each plugin's maintainer responsibility to transfer the issues from Jira to GH (with a pre-prepared solution I mentioned long ago).

I think we are still one step before: should we as project allow a diversity for issue tracking or should all maintainers use Jira? Until we have no such decision we should not discuss on how to actually do a migration. 


From standarisation and a common approach standpoint, forcing all plugins to use Jira would be reasonable if not for:
- stability problems
- maintenance problems (it is not updated frequently enough imo)
- lack of common process (I don't like for instance that we cannot use fixVersion in the workflow)

All of those could be probably addressed but OTOH, we are also too late with forcing to use Jira as a lot of plugins are already using GH issues and frankly as we discsussed before, I concur with GH Issues being closer to code/repository and easier for maintainers.
So, if each repository/plugin has it's own maintainer and noone from the umbrella organisation, then it should be up to the plugin maintainers to decide what they use - and we already see the tendency here.

Gavin Mogan

unread,
Jun 10, 2020, 8:57:53 PM6/10/20
to Jenkins Developers
personally, as someone who replies to emails/tickets on my phone a lot, I'd love to see everything migrated from self hosted jira to github, and have one less item that the infra team needs to manage. Plus easier for people to report bugs since they don't need to make an ldap account first

--
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-de...@googlegroups.com.

Brian Thompson

unread,
Jun 10, 2020, 10:49:21 PM6/10/20
to jenkin...@googlegroups.com
I agree.  I'd love to see Jenkins migrate from Jira to GH.  As a user, if I want to submit an issue to Jenkins, it's a bit cumbersome to create an additional account for Atlassian just so that I can create a ticket.  However, it's highly likely that I already have a GH account and have even browsed the codebase a bit or cloned the repo myself from GH.  So having the issues right where I am makes my life easier.



--
Best regards,

Brian

Slide

unread,
Jun 11, 2020, 10:33:17 AM6/11/20
to Jenkins Developer List
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

Tim Jacomb

unread,
Jun 11, 2020, 11:13:59 AM6/11/20
to Jenkins Developers
Wouldn't you either transfer it or ask them to re-file with the correct component?
Same as with Jira?

I doubt issues filed with the wrong component in Jira are ever seen by the right people either.

Thanks
Tim

Jeff Thompson

unread,
Jun 11, 2020, 11:26:33 AM6/11/20
to jenkin...@googlegroups.com
On 6/11/20 8:32 AM, Slide wrote:
The big problem with GitHub issues is when a bug involves multiple components, or is filed against the wrong component. If you filed an issue in the wrong component, what would you expect the maintainers of that component to do? I don't think it should be on them to find the right component, so the issue just gets closer and possibly not seen by the correct people? I definitely prefer GitHub issues, but we need to address some issues like I describe above.

These are the big issues with moving away from a system-wide tracker to individual trackers. Jenkins is a system of interacting components and issues may involve multiple.

As Remoting maintainer I see this frequently. Someone may submit an issue against Remoting, but often it has to do with a plugin and just shows up in Remoting. Eventually Remoting is removed from the components list and the correct one is assigned. Then the maintainer of that one has notification. Sometimes it helps define the problem. Someone submits the issue against Remoting and a plugin that might show up in the stack trace or messages. I look at it and have no idea, but the maintainer of the other component quickly identifies it.

Sometimes something is submitted against core but we decide it needs to be fixed somewhere else. Or vice versa.

And then there are security issues. We manage security issues as a Jenkins system.

If we switch to tracking issues solely by individual component we're going to lose track of a lot of things. Well, a lot more than we already do.

Jeff

Jesse Glick

unread,
Jun 11, 2020, 12:16:37 PM6/11/20
to Jenkins Dev
On Thu, Jun 11, 2020 at 11:26 AM Jeff Thompson <jtho...@cloudbees.com> wrote:
> Jenkins is a system of interacting components and issues may involve multiple.

Every time I have worked with a Jira issue with multiple components, I
have wound up regretting the resulting confusion. It gets marked fixed
by one person due to a fix in one repository, but something else still
needs to be done in another repository, etc. So long as a repository
corresponds to an actual artifact and an actual version number, it is
advisable to just have one issue per repository and link them
textually as needed. (Once the code associated with the issue is
clear! Before then, you can just transfer an issue.)

While I generally find GH issues far more comfortable to work with,
the search options are terrible compared to JQL.

Ullrich Hafner

unread,
Jun 11, 2020, 1:25:50 PM6/11/20
to Jenkins Developers
I prefer Jira, from a developer and a user perspective:

Developer perspective:
- Having the ability to move issues from one component to another is very helpful for me. I don’t see how to do this in GitHub. My plugin uses different components and I want to easily move issues from one component to other components. Also it is very helpful to create issues that affect several components. It makes inter-project communication much simpler.
- I also think that Jira has far more powerful features: dashboards, Kanban boards, epics and sub-tasks, powerful search, IntelliJ integration, workflows, issue resolution (resolved, fixed, duplicate, etc.), searchable IDs like JENKINS-50000 that you can enter in Google Search, just to name a few. It even has a wonderful mobile App (that we currently can’t use since our Jira version is sooo old).

Users perspective:
- Searching for all existing issues in Jira is very easy. Selecting multiple components if the reporter is not sure about the right component is also very simple. I think users will be annoyed if they need to switch between two different systems just because the issue has been reported in a wrong component and in the wrong issue tracker. 

I understand that GitHub also has some benefits, like a smooth integration with commits and PRs, or the fact that we do not need to host it. GitHub is also fast and modern (but Jira 8.x improved a lot on that side, maybe it would help to upgrade to a more recent version on our side).  

--
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-de...@googlegroups.com.

James Nord

unread,
Jun 11, 2020, 5:28:21 PM6/11/20
to Jenkins Developers
I agree with Ulli's statements.

There seems to be comments that our hosted Jira is sluggish or hard to maintain. I've asked before but why can,t the cloud version be an option?
we should be able to spin up a stateless SAML to LDAP integration for Jira Cloud with much less effort than continuing to patch/maintain our own Jira (and pay for the infra)?
maybe it's a license thing, in which case could we approach atlassian and ask?
I think many project are not wanting to use GH issues and so it seems that improving Jira would make things better for everyone even if it is not what some would desire in the end.

Slide

unread,
Jun 11, 2020, 5:29:56 PM6/11/20
to jenkin...@googlegroups.com
The issue with the cloud version is that it is not compatible with our LDAP (at least that is what I believe Olivier said last 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-de...@googlegroups.com.


--

Gavin Mogan

unread,
Jun 11, 2020, 5:43:54 PM6/11/20
to Jenkins Developers
According to https://issues.jenkins-ci.org/browse/INFRA-2010?jql=text%20~%20%22jira%22%20and%20text%20~%20%22ldap%22%20and%20text%20~%20%22cloud%22 there's also an issue that you can't import only 5k users total, and we have more than 100k users.

https://confluence.atlassian.com/cloud/saml-single-sign-on-943953302.html says saml is an option, and keycloak hooks up to ldap pretty easily and provides saml, so it might be doable.

Personally i want consistency, if some is in jira and some in github, its frustrating when people ask how to report things

Dominik Bartholdi

unread,
Jun 12, 2020, 12:07:05 AM6/12/20
to Jenkins Developers
I fully agrees with Uli and James… the main reason for me is the searchability of the issue IDs. Many many times I have the JIRA Issue ID (e.g. in commits) and then a simple Google search brings up the exact issue - with GH-Issues, this gets lost all the way :(
/Domi

Radosław Antoniuk

unread,
Jun 18, 2020, 12:00:38 PM6/18/20
to jenkin...@googlegroups.com
On Fri, Jun 12, 2020 at 6:07 AM Dominik Bartholdi <do...@fortysix.ch> wrote:
I fully agrees with Uli and James… the main reason for me is the searchability of the issue IDs. Many many times I have the JIRA Issue ID (e.g. in commits) and then a simple Google search brings up the exact issue - with GH-Issues, this gets lost all the way :(

 
On 11 Jun 2020, at 19:25, Ullrich Hafner <ullrich...@gmail.com> wrote:

I prefer Jira, from a developer and a user perspective:

Developer perspective:
- Having the ability to move issues from one component to another is very helpful for me. I don’t see how to do this in GitHub. My plugin uses different components and I want to easily move issues from one component to other components. Also it is very helpful to create issues that affect several components. It makes inter-project communication much simpler.

I support what Jesse Glick earlier wrote - our component configuration actually makes the Jira functionality totally useless in terms of things like fixVersion/affectedVersion when all components share the same project - at least in the current configuration shape.
 
- I also think that Jira has far more powerful features: dashboards, Kanban boards, epics and sub-tasks, powerful search, IntelliJ integration, workflows, issue resolution (resolved, fixed, duplicate, etc.), searchable IDs like JENKINS-50000 that you can enter in Google Search, just to name a few. It even has a wonderful mobile App (that we currently can’t use since our Jira version is sooo old).

The superiority of Jira in terms of features is obvious but it shouldn't be an argument. Most of the projects do not use Sprint Boards etc. and I still think that we should aim to be as close/easy for the contributor/reporter as possible. Most of searchability is achievable via milestones and labels with the additional advantages like auto-labelling by a bot according to PR size etc.

I've just tested this:
Search for CVSS in jira-plugin issues in my fork, via the global search option (top left):
https://github.com/search?q=user%3Awarden+cvss&type=Issues - on my whole account (if I want cross-component search)

Maybe we should list all usecases that are being used and try to create a migration table to see if we are missing any crucial stuff?

I obviously agree that one of the benefits is indexability of JENKINS-xxxx names by Google that we would loose...
OTOH, it's rather a matter of workflow, right? 
I mean, I don't think you ever remember the issue ID to search in Google, you search for it from the commit message, which if linked properly should work fine (see first link)
 
Users perspective:
- Searching for all existing issues in Jira is very easy. Selecting multiple components if the reporter is not sure about the right component is also very simple. I think users will be annoyed if they need to switch between two different systems just because the issue has been reported in a wrong component and in the wrong issue tracker. 
All Jenkins plugins are under the same GH account, IMHO the search UI is actually easier than Jira with lot of dropdown - says Atlassian software lover - but still, Jira is more for product teams in my opinion and for OSS GitHub is just simpler and enough with the advancements they made.

I understand that GitHub also has some benefits, like a smooth integration with commits and PRs, or the fact that we do not need to host it. GitHub is also fast and modern (but Jira 8.x improved a lot on that side, maybe it would help to upgrade to a more recent version on our side). 

Now another point, does the Keycloak/Linux Foundation for current Auth/AuthZ thread have any influence on this? 
Would it make it possible to use Jira Cloud when using any of those?

About consistency, I fully agree, but we are already past that point as the plugins are already mixed up between Jira and GH.
So unless we want to make a forced pushback to Jira, I would try to make use of the current situation to migrate to either Jira Cloud or GH Issues to get rid of maintenance (and old version) burden, since the blog is also moving out of Confluence.


Cheers,
Radek


Tim Jacomb

unread,
Jun 18, 2020, 12:11:01 PM6/18/20
to jenkin...@googlegroups.com
Hi Radek

Jira cloud isn’t an option due to our number of users and a couple of other reasons (there’s a ticket with a summary somewhere in jira)

Linux foundation have offered to host jira though which may at least get us one we don’t have to maintain.

Fully agree with your other points

Maybe we need an evaluation with an updated Jira as some people have said the newer one is better.

I find working with GitHub issues far superior than Jira, and think that we should do more to support GitHub issues, defaulting to enabling it on new plugins, and showing them in the plugin site etc

A document with what people are using each for could be useful? Although the chat discussion hasn’t seemed to have gone anywhere.

One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in Jira

Thanks

Tim 


--
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-de...@googlegroups.com.

Ullrich Hafner

unread,
Jun 18, 2020, 12:51:12 PM6/18/20
to Jenkins Developers


> Am 18.06.2020 um 18:00 schrieb Radosław Antoniuk <radek.a...@gmail.com>:
>
> The superiority of Jira in terms of features is obvious but it shouldn't be an argument.

Why not?

> Most of the projects do not use Sprint Boards etc. and I still think that we should aim to be as close/easy for the contributor/reporter as possible. Most of searchability is achievable via milestones and labels with the additional advantages like auto-labelling by a bot according to PR size etc.
>
> Maybe we should list all usecases that are being used and try to create a migration table to see if we are missing any crucial stuff?
>

Maybe it would make sense to collect all arguments in a document so we can discuss it in the Governance meeting and make a decision on how to proceed.

>
> About consistency, I fully agree, but we are already past that point as the plugins are already mixed up between Jira and GH.

I don’t think that we are past the point yet, just because a couple of plugins managed it to enable GitHub issues. From my understanding the hosting process creates a Jira component and GitHub Issues is disabled for the repository.


Slide

unread,
Jun 18, 2020, 1:04:29 PM6/18/20
to jenkin...@googlegroups.com
>
> About consistency, I fully agree, but we are already past that point as the plugins are already mixed up between Jira and GH.

I don’t think that we are past the point yet, just because a couple of plugins managed it to enable GitHub issues. From my understanding the hosting process creates a Jira component and GitHub Issues is disabled for the repository.

People added to the develop group for the plugin have admin access to the repo, so enabling GitHub Issues is pretty easy. This is how some repos currently have GitHub Issues enabled now. 

--

Jesse Glick

unread,
Jun 18, 2020, 1:36:25 PM6/18/20
to Jenkins Dev
On Thu, Jun 18, 2020 at 12:51 PM Ullrich Hafner
<ullrich...@gmail.com> wrote:
>> we are already past that point as the plugins are already mixed up between Jira and GH.
>
> I don’t think that we are past the point yet, just because a couple of plugins managed it to enable GitHub issues.

jshell> for (GHRepository r :
GitHub.connect().getOrganization("jenkinsci").listRepositories())
{String n = r.getName(); if (n.endsWith("-plugin") && r.hasIssues())
{System.out.println(n + ": " +
r.getIssues(GHIssueState.ALL).stream().filter(i ->
!i.isPullRequest()).count());}}
rake-plugin: 14
rubymetrics-plugin: 24
accurev-plugin: 1
build-timeout-plugin: 9
cmvc-plugin: 1
configurationslicing-plugin: 1
cobertura-plugin: 60
doclinks-plugin: 2
extended-read-permission-plugin: 2
envfile-plugin: 1
greenballs-plugin: 1
ivy-plugin: 6
maven-repo-cleaner-plugin: 2
maven-dependency-update-trigger-plugin: 7
platformlabeler-plugin: 2
perfpublisher-plugin: 12
scm-sync-configuration-plugin: 40
scp-plugin: 4
sidebar-link-plugin: 1
violations-plugin: 45
depgraph-view-plugin: 2
selenium-plugin: 85
seleniumhtmlreport-plugin: 1
build-name-setter-plugin: 13
plasticscm-plugin: 15
klocwork-plugin: 9
ivytrigger-plugin: 0
urltrigger-plugin: 4
fstrigger-plugin: 1
ansicolor-plugin: 122
rrod-plugin: 1
graven-plugin: 0
dev-mode-plugin: 0
brakeman-plugin: 10
gradle-jpi-plugin: 22
junit-attachments-plugin: 5
silktestsuite-plugin: 1
antexec-plugin: 0
unity3d-plugin: 12
tikal-multijob-plugin: 81
fogbugz-plugin: 2
hipchat-plugin: 98
rbenv-plugin: 32
embeddable-build-status-plugin: 24
yammer-plugin: 5
stackhammer-plugin: 0
regression-report-plugin: 6
leiningen-plugin: 11
cas-plugin: 0
ghprb-plugin: 427
testswarm-plugin: 0
multi-module-tests-publisher-plugin: 6
gitlab-hook-plugin: 29
debian-package-builder-plugin: 25
periodic-reincarnation-plugin: 2
caliper-ci-plugin: 2
recipe-plugin: 0
vertx-plugin: 4
nis-notification-lamp-plugin: 1
audit2db-plugin: 17
coordinator-plugin: 40
slave-proxy-plugin: 0
appdynamics-plugin: 6
cucumber-reports-plugin: 220
stashnotifier-plugin: 156
tag-profiler-plugin: 0
cloudtest-plugin: 1
buildgraph-view-plugin: 9
trac-artifacts-publisher-plugin: 0
zulip-plugin: 16
cloudbees-enterprise-plugins-plugin: 0
wix-plugin: 9
rpmsign-plugin: 7
jqs-monitoring-plugin: 1
sra-deploy-plugin: 1
build-view-column-plugin: 0
rally-plugin: 18
categorized-view-plugin: 12
parallel-test-executor-plugin: 20
rest-service-scheduler-plugin: 0
team-views-plugin: 0
groovy-script-scheduler-plugin: 0
enhanced-old-build-discarder-plugin: 1
mount-point-disk-space-monitor-plugin: 0
mlattach-plugin: 0
newgen-servers-plugin: 0
ec2-cloud-axis-plugin: 1
kerberos-auth-plugin: 0
archived-artifact-url-viewer-plugin: 1
mesos-plugin: 180
junit-realtime-test-reporter-plugin: 1
proxmox-plugin: 3
trial-balloon-plugin: 0
jobtemplates-plugin: 1
selenium-axis-plugin: 2
slack-plugin: 425
lockable-resources-plugin: 98
pom2config-plugin: 0
gatekeeper-plugin: 1
implied-labels-plugin: 1
xlrelease-plugin: 2
docker-plugin: 506
deveo-plugin: 1
flowdock-plugin: 15
google-oauth-plugin: 41
google-storage-plugin: 45
packer-plugin: 18
google-metadata-plugin: 2
poll-mailbox-trigger-plugin: 52
artifact-promotion-plugin: 14
liquibase-runner-plugin: 15
failure-visualizer-plugin: 0
openid4java-plugin: 0
gitlab-plugin: 751
allure-plugin: 171
jabber-server-plugin: 5
azure-slave-plugin: 34
vmanager-plugin: 2
xltestview-plugin: 0
travis-yml-plugin: 2
icon-shim-plugin: 0
page-note-plugin: 0
lucene-search-plugin: 2
saltstack-plugin: 89
aws-beanstalk-publisher-plugin: 33
uithemes-plugin: 2
environment-plugin: 0
matrix-groovy-execution-strategy-plugin: 16
persistent-parameter-plugin: 5
dynatrace-plugin: 7
environment-dashboard-plugin: 50
discobit-autoconfig-plugin: 0
google-source-plugin: 6
font-awesome-icons-plugin: 0
ontrack-plugin: 47
openstack-cloud-plugin: 163
cli-commander-plugin: 1
jackson-databind-plugin: 0
advanced-installer-msi-builder-plugin: 0
inedo-buildmaster-plugin: 0
violation-comments-to-stash-plugin: 54
ssh2easy-plugin: 8
compound-slaves-plugin: 3
seed-plugin: 35
redgate-sql-ci-plugin: 5
sqlplus-script-runner-plugin: 46
azure-publishersettings-credentials-plugin: 0
aws-credentials-plugin: 29
openconnect-plugin: 1
datadog-plugin: 11
groovy-events-listener-plugin: 28
amazon-ecs-plugin: 87
sumologic-publisher-plugin: 3
tinfoil-scan-plugin: 0
git-changelog-plugin: 38
ecutest-plugin: 61
walti-plugin: 0
delphix-plugin: 4
readonly-parameter-plugin: 1
fortify-on-demand-uploader-plugin: 43
sap-hcp-deployer-plugin: 0
salesforce-migration-assistant-plugin: 21
octoperf-plugin: 1
violation-comments-to-github-plugin: 27
bitbucket-branch-source-plugin: 91
cloud-stats-plugin: 10
pipeline-view-plugin: 4
sge-cloud-plugin: 1
cucumber-living-documentation-plugin: 27
prometheus-plugin: 96
imagecomparison-plugin: 0
vncviewer-plugin: 2
vncrecorder-plugin: 1
github-pr-coverage-status-plugin: 44
scm-sqs-plugin: 8
nomad-plugin: 27
ibm-security-appscansource-scanner-plugin: 9
consul-kv-builder-plugin: 8
ec2-fleet-plugin: 111
cisco-spark-plugin: 1
office-365-connector-plugin: 69
oic-auth-plugin: 55
contrast-continuous-application-security-plugin: 2
last-changes-plugin: 69
fabric-beta-publisher-plugin: 25
open-stf-plugin: 7
gogs-webhook-plugin: 26
azure-batch-parallel-plugin: 0
statistics-gatherer-plugin: 12
hashicorp-vault-plugin: 24
aws-sqs-plugin: 21
gerrit-verify-status-reporter-plugin: 3
build-time-blame-plugin: 14
cisco-spark-notifier-plugin: 11
dingtalk-plugin: 36
pipeline-aws-plugin: 124
github-issues-plugin: 9
testrail-plugin: 39
jms-messaging-plugin: 24
github-pr-comment-build-plugin: 17
pipeline-dependency-walker-plugin: 1
aws-cloudwatch-logs-publisher-plugin: 10
device-watcher-plugin: 1
clif-performance-testing-plugin: 0
cloudshare-docker-plugin: 1
violation-comments-to-gitlab-plugin: 22
generic-webhook-trigger-plugin: 148
app-detector-plugin: 0
ibm-ucdeploy-pipeline-plugin: 7
livingdoc-reports-plugin: 0
dotnet-as-script-plugin: 2
ranorex-integration-plugin: 0
pipeline-github-plugin: 59
xlrelease-var-setter-plugin: 1
date-parameter-plugin: 5
cerberus-testing-plugin: 6
aws-codecommit-trigger-plugin: 5
rancher-plugin: 36
coding-webhook-plugin: 11
confluence-pipeline-steps-plugin: 1
outbound-webhook-plugin: 5
azure-cli-plugin: 17
osf-builder-suite-for-sfcc-deploy-plugin: 5
git-bisect-plugin: 7
docker-java-api-plugin: 0
pyenv-pipeline-plugin: 28
azure-container-agents-plugin: 22
azure-acs-plugin: 7
kubernetes-cd-plugin: 80
github-autostatus-plugin: 36
google-cloudbuild-plugin: 8
configuration-as-code-plugin: 608
telegram-notifications-plugin: 31
service-fabric-plugin: 7
benchmark-plugin: 16
azure-ad-plugin: 39
kubernetes-cli-plugin: 11
phoenix-autotest-plugin: 3
working-hours-plugin: 6
service-now-plugin: 8
genexus-plugin: 2
dev-notifier-plugin: 0
docker-swarm-plugin: 47
badge-plugin: 15
arestocats-plugin: 4
google-compute-engine-plugin: 88
code-coverage-api-plugin: 71
hugo-plugin: 2
clever-cloud-plugin: 0
osf-builder-suite-for-sfcc-data-import-plugin: 3
influxdb-query-plugin: 13
aqua-microscanner-plugin: 9
overops-query-plugin: 8
jaxb-plugin: 1
osf-builder-suite-xml-linter-plugin: 0
habitat-plugin: 7
osf-builder-suite-standalone-sonar-linter-plugin: 0
llvm-cov-plugin: 5
cachet-gating-plugin: 4
google-chat-notification-plugin: 19
plasticscm-mergebot-plugin: 0
localization-zh-cn-plugin: 26
aws-sam-plugin: 9
redmine-metrics-report-plugin: 0
in-toto-plugin: 5
zap-pipeline-plugin: 9
multibranch-job-tear-down-plugin: 1
discord-notifier-plugin: 18
audit-log-plugin: 24
log-sanitizer-plugin: 1
bitbucket-push-and-pull-request-plugin: 50
lambda-test-runner-plugin: 4
testproject-plugin: 0
cons3rt-plugin: 0
google-kubernetes-engine-plugin: 37
eiffel-broadcaster-plugin: 3
azure-keyvault-plugin: 20
fortify-plugin: 9
templating-engine-plugin: 47
deepsecurity-smartcheck-plugin: 4
maven-snapshot-check-plugin: 4
config-driven-pipeline-plugin: 2
pipeline-config-history-plugin: 4
git-automerger-plugin: 1
multi-branch-priority-sorter-plugin: 1
remote-file-plugin: 0
sweagle-plugin: 14
pipeline-restful-api-plugin: 1
multibranch-action-triggers-plugin: 1
build-history-manager-plugin: 1
xray-connector-plugin: 6
opencover-plugin: 3
concurrent-step-plugin: 4
pipeline-global-lib-nexus-plugin: 2
osf-builder-suite-for-sfcc-run-job-plugin: 0
s3explorer-plugin: 0
conjur-credentials-plugin: 1
aws-lambda-cloud-plugin: 4
pipeline-as-yaml-plugin: 7
dark-theme-plugin: 42
theme-manager-plugin: 3

Ullrich Hafner

unread,
Jun 18, 2020, 1:41:16 PM6/18/20
to Jenkins Developers
Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-( 

Am 18.06.2020 um 19:36 schrieb Jesse Glick <jgl...@cloudbees.com>:

stashnotifier-plugin

Gavin Mogan

unread,
Jun 18, 2020, 1:49:19 PM6/18/20
to Jenkins Developers
> Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-( 

Which is why I want to know what and how we want to support things officially so I can add it to the plugin site.

> The superiority of Jira in terms of features is obvious but it shouldn't be an argument

Just FYI, any time you use the word obvious, its actually not obvious. If its obvious it wouldn't need to be said, but if you say obvious, then something is clear to you, and not to the other people.



Another option is to do what some open source repos do, and have a single repo just for issues


Which would let people use github, could even be github and jira split that way, but still give the power for user to report bugs in a single place, and then triage with labels or something.

I think we have too many components to do that, but it would be another way to handle it.

Gavin


--
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-de...@googlegroups.com.

Ullrich Hafner

unread,
Jun 18, 2020, 2:12:24 PM6/18/20
to Jenkins Developers

> Am 18.06.2020 um 19:48 schrieb 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com>:
>
> > Puh, that is a lot. That means we already cerated a mess for our users by providing two different tools for the same thing :-(
>
> Which is why I want to know what and how we want to support things officially so I can add it to the plugin site.
>

Wouldn’t it then make sense that the people who want officially support GitHub as a second issue tracker would make that an agenda topic for the next governance meeting?
So we can finally come to an official statement? Otherwise this thread will continue indefinitely.

Slide

unread,
Jun 18, 2020, 2:44:22 PM6/18/20
to jenkin...@googlegroups.com
Agreed, I think we need to have this as a topic in that meeting. 

I think there are two parts of this topic:
  1. Do we want to allow both Jira and Github issues to coexist in the Jenkins infrastructure? 
    1. This is _somewhat_ moot at this point because we already have a large number of repos that have Github Issues enabled already.
    2. If we want to allow both, do we need to clean up the Jira components of those plugins that are using Github Issues by providing a way to migrate issues from Jira to Github Issues and then removing the component? Also, the opposite, if the plugin developers want to use Jira but Github Issues was enabled on their repository without them wanting it enabled (this could have happened for many reasons), do we need to cleanup the Github Issues and provide a way to migrate issues from Github Issues to Jira?
  2. Do we want to adjust the hosting process to allow selection of the issue tracking (Github Issues or Jira)?
    1. This would mean that the hosting bot would check that field and either:
      1. Create a component in Jira and disable GitHub issues for the repo (this does not preclude the plugin developers team members from re-enabling GitHub Issues after the fact)
      2. No creation of a component in Jira and GitHub issues are NOT disabled

Am I missing anything from this thread?

--
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-de...@googlegroups.com.


--

James Nord

unread,
Jun 18, 2020, 4:43:56 PM6/18/20
to Jenkins Developers
> am I missing something in this thread

security reports?

currently they are all triaged by the security team so the team can track disclosure deadlines etc.
how would that worknif the plugin is usimg GH issues? (yes I know gh issues can now handle security reports but does that mean the security team members need admin on all plugin repos, are they supposed to be watching more places for reports etc)

/James

Tim Jacomb

unread,
Jun 18, 2020, 4:50:52 PM6/18/20
to Jenkins Developers
The security team already uses a different project in Jira to everyone else, I don't think we need to change that currently, maintainers will just use whatever the security team decides I would think?

Mentioned this earlier:
> One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in Jira



 
--
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-de...@googlegroups.com.

Tim Jacomb

unread,
Jun 19, 2020, 4:29:17 AM6/19/20
to Jenkins Developers
To add to Jesse's numbers here's a summary for the JenkinsCI organisation:

Org report: jenkinsci
Total repositories: 2290
Number with GitHub issues enabled: 355 (15%)
Total issues open: 3338
Total issues closed: 17941
Total issues: 21279


Thanks
Tim

Daniel Beck

unread,
Jun 19, 2020, 5:36:46 AM6/19/20
to Jenkins Developers


> On 18. Jun 2020, at 22:50, Tim Jacomb <timja...@gmail.com> wrote:
>
> The security team already uses a different project in Jira to everyone else, I don't think we need to change that currently, maintainers will just use whatever the security team decides I would think?
>
> Mentioned this earlier:
> > One thing I think is important to mention is that the security project can be a special case and should be fine to either stay on jira or possibly there’s a better tool for it, we shouldn’t block a move because the security project has a very well defined process that works well in Jira

I already explained earlier that the effectiveness of our work depends on maintainers getting, and then not just ignoring, notifications from Jira. That's made more difficult when they don't use it. Depending on how you count we have between 1 and 4 people contacting maintainers for hundreds of issues a year, anything that makes this more effort or introduces delays will negatively impact our effectiveness.

Additionally, with the vast majority of issues being tracked in Jira, we can fairly easily subscribe to the feed of new issues and move publicly reported vulnerabilities into the private tracker. That doesn't exist on GitHub.

Similarly, users should be able to report security issues without having to jump through hoops. Right now, that's done by accepting reports via email and in the issue tracker most other stuff uses anyway.

I would be surprised if we wouldn't regularly get 0-days because people with just a GH account don't bother to do it properly, and just report issues on GH. If that is enabled in repos without someone regularly reviewing incoming issues, or by a maintainer who's unaware of how we handle security issues in the project, reports may linger in public for months or even years.

Having a screen like https://github.com/jenkinsci/configuration-as-code-plugin/issues/new/choose could help here, but that's far from universal right now. Is this something that could be defined via .github? Having a screen similar to this would be the bare minimum for GH issue tracking already today.

Radosław Antoniuk

unread,
Jun 19, 2020, 5:48:27 AM6/19/20
to jenkin...@googlegroups.com
I would be surprised if we wouldn't regularly get 0-days because people with just a GH account don't bother to do it properly, and just report issues on GH. If that is enabled in repos without someone regularly reviewing incoming issues, or by a maintainer who's unaware of how we handle security issues in the project, reports may linger in public for months or even years.

How about just using "security" label that shall be added by the maintainer and pull all labelled issues automatically via a bot?

 

Daniel Beck

unread,
Jun 19, 2020, 6:12:55 AM6/19/20
to Jenkins Developers


> On 19. Jun 2020, at 11:47, Radosław Antoniuk <radek.a...@gmail.com> wrote:
>
>> I would be surprised if we wouldn't regularly get 0-days because people with just a GH account don't bother to do it properly, and just report issues on GH. If that is enabled in repos without someone regularly reviewing incoming issues, or by a maintainer who's unaware of how we handle security issues in the project, reports may linger in public for months or even years.
>
> How about just using "security" label that shall be added by the maintainer and pull all labelled issues automatically via a bot?

How would that work

> in repos without someone regularly reviewing incoming issues, or by a maintainer who's unaware of how we handle security issues in the project


?

Tim Jacomb

unread,
Jun 19, 2020, 6:30:30 AM6/19/20
to Jenkins Developers
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <m...@beckweb.net> wrote:
Having a screen like https://github.com/jenkinsci/configuration-as-code-plugin/issues/new/choose could help here, but that's far from universal right now. Is this something that could be defined via .github? Having a screen similar to this would be the bare minimum for GH issue tracking already today.

Yes that is possible, I've just tested it out:

(I don't have the security file in my org but it would show up if it was configured)

Thanks
Tim
 
--
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-de...@googlegroups.com.

Radosław Antoniuk

unread,
Jun 19, 2020, 6:58:35 AM6/19/20
to jenkin...@googlegroups.com
On Fri, Jun 19, 2020 at 12:30 PM Tim Jacomb <timja...@gmail.com> wrote:
On Fri, 19 Jun 2020 at 10:36, Daniel Beck <m...@beckweb.net> wrote:
Having a screen like https://github.com/jenkinsci/configuration-as-code-plugin/issues/new/choose could help here, but that's far from universal right now. Is this something that could be defined via .github? Having a screen similar to this would be the bare minimum for GH issue tracking already today.

Yes that is possible, I've just tested it out:

(I don't have the security file in my org but it would show up if it was configured)
 
Nice, exactly that.
So, security report via a template, that auto-adds "security" label, that can be pulled into (or referenced) a central security project.

Olblak

unread,
Jun 23, 2020, 7:20:32 AM6/23/20
to Jenkins Developers ML
Hi,

I think this mail discussion is a proof that we won't easily find a consensus any time soon.
I just want to add that we started discussing with Linux foundation  infra team to see if they could maintained a managed version of Jira for us, more information in this email.

So please keep discussing about Jira and/or Github Issues here and things specific to how we maintain issues.jenkins-ci.org on the other thread.

Cheers 
--
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-de...@googlegroups.com.

Radosław Antoniuk

unread,
Jun 24, 2020, 11:17:31 AM6/24/20
to jenkin...@googlegroups.com

Since now we know we have the GH issues templates... what do you think about creating a central (i.e. pre-defined and shared across all plugins), how about:
- creating a unified GH issue template for the whole jenkinsci organisation (i.e. pre-defined template)
- push this template via PR to all the plugin repositories (regardless of whether they use Jira or GH)
- automatically create new plugin repositories with this template
- (?) create a bot that would pull all "security" labelled issues into Jira security project or wherever it may be

?

Radek

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/haFTYlhp7h8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/016c48f3-1c26-4d43-9abb-897560659eab%40www.fastmail.com.

Tim Jacomb

unread,
Jun 24, 2020, 11:59:46 AM6/24/20
to Jenkins Developers
On Wed, 24 Jun 2020 at 16:17, Radosław Antoniuk <radek.a...@gmail.com> wrote:

Since now we know we have the GH issues templates... what do you think about creating a central (i.e. pre-defined and shared across all plugins), how about:
- creating a unified GH issue template for the whole jenkinsci organisation (i.e. pre-defined template)
- push this template via PR to all the plugin repositories (regardless of whether they use Jira or GH)
- automatically create new plugin repositories with this template
- (?) create a bot that would pull all "security" labelled issues into Jira security project or wherever it may be

I agree it would be good to create the GitHub issue templates in the .github repository

Not sure why we would need to create a PR to all plugin repositories as GitHub will automatically use the central one if there isn't one in the repository

There's a PR to archetypes which adds all of our standard files that make plugin maintenance easier:

Thanks
Tim

 

Gavin Mogan

unread,
Jul 26, 2020, 6:28:49 PM7/26/20
to Jenkins Developers
I know there's no consensus in this yet, it should get added to governance i think, but I'm fixing github issue ids in release notes


Radek Antoniuk

unread,
Feb 15, 2021, 2:32:24 PM2/15/21
to jenkin...@googlegroups.com

Daniel Beck

unread,
Feb 15, 2021, 4:12:43 PM2/15/21
to Jenkins Developers


> On 15. Feb 2021, at 20:32, Radek Antoniuk <radek.a...@gmail.com> wrote:
>
> Regarding Security issues - maybe GH new Security Advisories hub could be used for that?
> https://help.github.com/en/github/managing-security-vulnerabilities/about-github-security-advisories
> https://github.blog/2020-05-26-giving-credit-for-security-advisories/

Our usual workflow is documented in some detail in https://www.jenkins.io/security/for-maintainers/ and I don't see how this helps with that at all. Could you elaborate?

Radek Antoniuk

unread,
Feb 21, 2021, 10:50:40 AM2/21/21
to jenkin...@googlegroups.com
>> Regarding Security issues - maybe GH new Security Advisories hub could be used for that?

> Our usual workflow is documented in some detail in https://www.jenkins.io/security/for-maintainers/ and I don't see how this helps with that at all. Could you elaborate?

Thanks for the link. I'm imagining it in exactly the same way because GH follows the same principle for security vulnerabilities reporting:

Let me know if I missed something but for me this process looks exactly the same when we replace Jira with GH Security Advisories system described above.
The only thing I see missing here is probably the possibility for non-write members to be able to create the private security advisory but I can imagine this could be solved via a workflow or a common mailbox.

Other than that, do you have any review comments on https://github.com/jenkinsci/.github/pull/42 ?



-- 
Sent with Shift

Daniel Beck

unread,
Feb 24, 2021, 4:20:00 PM2/24/21
to Jenkins Developers


> On 21. Feb 2021, at 16:50, Radek Antoniuk <radek.a...@gmail.com> wrote:
>
>
> Let me know if I missed something but for me this process looks exactly the
> same when we replace Jira with GH Security Advisories system described
> above.
> The only thing I see missing here is probably the possibility for non-write
> members to be able to create the private security advisory but I can
> imagine this could be solved via a workflow or a common mailbox.

The "only thing missing" is a major reason we use Jira. And we've been pretty terrible at mailboxes for years. The HOSTING Jira only exists because of that. If people started reporting via email in large numbers, we'd simply fold.

At first I had a giant wall of text here, explaining in detail why it's unnecessary, but really it boils down to GitHub Security Advisories not offering a single thing we want or need, and don't already do (often better). I'm really curious what you think we'd get in return for a _lot_ of additional work, both migration and ongoing, here.

Reply all
Reply to author
Forward
0 new messages