Proposal: Move Jenkins Test Harness issue tracker to GitHub Issues

113 views
Skip to first unread message

Oleg Nenashev

unread,
Oct 17, 2021, 4:50:21 AM10/17/21
to Jenkins Developers
Hi all,

I suggest moving the Jenkins Test Harness issue tracker to GitHub Issues. This is a test framework, and it is not exposed to the user ecosystem. Using GitHub issues would be ore convenient for use-cases, and particularly for onboarding new contributors. What do you think?


Best regards,
Oleg

Tim Jacomb

unread,
Oct 17, 2021, 6:05:17 AM10/17/21
to Jenkins Developers
+1

--
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/2c71f107-a566-40ab-bd7d-88e6d7207472n%40googlegroups.com.

Oleg Nenashev

unread,
Oct 17, 2021, 9:58:15 AM10/17/21
to Jenkins Developers
I would actually expand that to all developer tools we have in the project
They are isolated from distributions, and hence it does not make much sense to keep them in the integrated Jira

Daniel Beck

unread,
Oct 17, 2021, 10:14:46 AM10/17/21
to Jenkins Developers


> On 17. Oct 2021, at 10:50, Oleg Nenashev <o.v.ne...@gmail.com> wrote:
>
> I suggest moving the Jenkins Test Harness issue tracker to GitHub Issues. This is a test framework, and it is not exposed to the user ecosystem. Using GitHub issues would be ore convenient for use-cases, and particularly for onboarding new contributors. What do you think?
>

Makes sense.

Jesse Glick

unread,
Oct 18, 2021, 9:28:48 AM10/18/21
to Jenkins Dev
On Sun, Oct 17, 2021 at 9:58 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
I would actually expand that to all developer tools we have in the project

Yes! At a minimum
  • jenkins-test-harness
  • pom
  • plugin-pom
  • bom
  • maven-hpi-plugin
  • incrementals-tools
  • acceptance-test-harness
  • archetypes
  • custom-war-packager
  • docker-fixtures
  • jenkins-test-harness-htmlunit
  • jenkins-test-harness-tools
  • plugin-compat-tester

Jesse Glick

unread,
Oct 18, 2021, 9:33:44 AM10/18/21
to Jenkins Dev
On Sun, Oct 17, 2021 at 4:50 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
Currently we have only a few issues in Jira

BTW if switching canonical issue tracker I recommend also closing any remaining open issues in Jira and refiling them in GitHub (with links in either direction for reference). 

Tim Jacomb

unread,
Oct 18, 2021, 10:12:11 AM10/18/21
to jenkin...@googlegroups.com
+1 to Jesse’s list

--
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.

Oleg Nenashev

unread,
Oct 19, 2021, 2:35:20 AM10/19/21
to Jenkins Developers
I am +1 too. I switched Jenkins Test Harness taking the feedback.
Will give it a bit more time for the rest of the repositories

Baptiste Mathus

unread,
Oct 19, 2021, 4:53:19 AM10/19/21
to Jenkins Developers

Jesse Glick

unread,
Jan 11, 2022, 9:59:28 AM1/11/22
to jenkin...@googlegroups.com
Anyone with infra-level permissions up for this? I just tried to switch `maven-hpi-plugin` to GH Issues but noticed I lack admin access to the repo (and certainly I would lack permissions to mark a Jira component closed for entry of new issues, which I think is an option).

Oleg Nenashev

unread,
Jan 11, 2022, 10:45:40 AM1/11/22
to Jenkins Developers
Hi Jesse,

Enabled it for all remaining projects in the list.

BR, Oleg

Tim Jacomb

unread,
Jan 12, 2022, 7:23:35 AM1/12/22
to Jenkins Developers
I archived the component in Jira for the ones I found, not all of them mapped to a component and I didn't dig too hard.
Archiving seems to keep the component there but no new issues can be added which maps to what you said Jesse

Anyone can migrate the issues, Herve is the one who did this most recently:



--
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.

Basil Crow

unread,
Apr 27, 2022, 5:43:33 PM4/27/22
to jenkin...@googlegroups.com
Strong -1 from me. Using GitHub issues for core components but not
core itself makes it impossible to do project management in a single
view (Jira epic or GitHub project) that covers both core and core
components. Additionally, there is no way to define causal
relationships or dependencies between GitHub issues, which is also
essential for project management. Please roll back whatever change now
prevents me from creating new Jira issues for core components.

Oleg Nenashev

unread,
Apr 27, 2022, 6:12:14 PM4/27/22
to JenkinsCI Developers
Jenkins Test Harness is not a core component, it is a separate deliverable with its own release lifecycle
Same for other developer tools AFAICT


--
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/9sZipk1PHns/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/CAFwNDjpy_QzJ0v4RqUJkDw2migG_RoaX856rJienKLgD%2BxVs%3DQ%40mail.gmail.com.

Daniel Beck

unread,
Apr 28, 2022, 4:22:16 AM4/28/22
to jenkin...@googlegroups.com
On Thu, Apr 28, 2022 at 12:20 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
Jenkins Test Harness is not a core component, it is a separate deliverable with its own release lifecycle
Same for other developer tools AFAICT

Not part of the core deliverable, but core team repos. Projects still likely cross issue trackers. 

Basil Crow

unread,
May 23, 2022, 2:55:02 PM5/23/22
to jenkin...@googlegroups.com
On Thu, Apr 28, 2022 at 1:22 AM 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
> Not part of the core deliverable, but core team repos. Projects still likely cross issue trackers.

Yes. In jenkins-infra/helpdesk#2819 it was suggested that "we could use something like core, unsorted, or something more specific that means this is a tracking issue only for use in a larger project." Not only does this add additional (and unwanted!) burden on project managers to create the tracking issues, but also it does not address the regression that I reported in jenkins-infra/helpdesk/issues/2819 (comment): prior to the archiving of the packaging component, I could have easily moved JENKINS-68600 to the correct component, but now the functionality to correct the component of a misfiled issue is not available to me. The suggested workaround is both burdensome and incomplete. In short, the suggested workaround is not acceptable to me.

The migration of core components to GitHub issues was incomplete. It was incomplete in the sense that it only established the use of GitHub for new core component issues but did not migrate existing core component issues from Jira to GitHub. It was incomplete because it covered core components but not itself, breaking project management use cases. It was incomplete because it broke the existing workflow documented in the Issue Reporting page in the documentation without documenting the proposed new workflow, leading to confusion for end users. It was incomplete because it did not describe a way to move issues filed in an incorrect component to the correct component, breaking existing issue triage use cases.

Completing this migration is a formidable task. The incomplete migration is causing problems for me as I work on issue triage and project management, and it is causing confusion for end users who have filed packaging tickets in the wrong place multiple times. Pending the delivery of a complete migration, please restore the status quo and move core components back to Jira. This is a simple action that would resolve all of the problems that I have reported and does not preclude a complete migration from taking place in the future.

Ullrich Hafner

unread,
May 23, 2022, 3:18:46 PM5/23/22
to JenkinsCI Developers
As mentioned several times before I think that using or allowing 2 different issue tracker systems for *any* Jenkins component (core and plugins) is a mess for users and developers.   

--
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/CAFwNDjpYjyzk6bhuzQZTSe6PePDRbBaN2gbgLc4%2B7BzpPVoSSw%40mail.gmail.com.

Basil Crow

unread,
May 23, 2022, 3:33:40 PM5/23/22
to jenkin...@googlegroups.com
On Mon, May 23, 2022 at 12:18 PM Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> As mentioned several times before I think that using or allowing 2 different issue tracker systems for *any* Jenkins component (core and plugins) is a mess for users and developers.

Indeed, though at least the mess is mitigated for plugins through the use of appropriate links such as "Open issues (Github)" or "Open issues (Jira)" on the Plugin Site. This helps users to know where to go, though the problems with project management (tracking projects that span multiple plugins) and issue triage (being able to efficiently move an issue from the incorrect component to the correct component) remain. In contrast, the Issue Reporting page clearly assumes the use of Jira, so it is natural for users to file tickets for core and core components in Jira since we do not direct them anywhere else in the documentation. That is why I am asking for us to (a) stop accepting new issues on GitHub for all core components and (b) move any existing core component issues from GitHub to Jira. This at least restores the working status quo for core and core components by using a consistent issue tracker for both that also matches the documentation and restores the project management and issue triage use cases mentioned above. I am defining "core component" as "any component whose developer list in RPU includes @core".
Reply all
Reply to author
Forward
0 new messages