Migration plan for core components to Jira

193 views
Skip to first unread message

Tim Jacomb

unread,
Nov 12, 2025, 7:53:02 AMNov 12
to Jenkins Developers
Hi all

Given all the feedback has been positive and all questions resolved, I would like to propose a migration plan.


Step #

Date

Est. time

Title

1

13/11

5min

Create status.jenkins.io issue

2

17/11

10min

Enable GitHub issues and create a pinned issue announcing migration

3

19/11

2min

Announce to jenkinsci-dev that migration is starting

4

19/11

2min

Archive component in Jira to prevent new issues being created

5

19/11

5-10min

Export issues

6

19/11

2min

Set shell variables (access token not provided in script, fill it in for the jira importer user)

7

19/11

2min

Create allowed_labels.txt file

8

19/11

~15 hours

Run migration script

10

20/11

2 hours

Run epic processing script

11

20/11

12 hours

Run issue processing script

9

21/11

8 hours

Run issue commenter script

12

21/11

5min

Create mapping file

13

21/11

2min

Announce to jenkinsci-dev that migration is completed


Happy to push it back a week or some, from a migration script PoV we have everything we need. Herve is planning a couple of improvements to make the issue processing script faster.

Last example migration:

Example Jira issue with migration comment:

Thanks
Tim

Daniel Krämer

unread,
Nov 12, 2025, 9:44:02 AMNov 12
to Jenkins Developers
Sounds like a solid plan. Thank you so much for doing this.
Only addition I'd suggest is to also warn users in Jira that the migration is happening and user can already use the GitHub issues (once enabled). Adding a banner of some sorts should be possible, no?

Tim Jacomb

unread,
Nov 12, 2025, 10:56:57 AMNov 12
to jenkin...@googlegroups.com
Good idea I've created a banner (turned off until Monday)

image.png

--
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 visit https://groups.google.com/d/msgid/jenkinsci-dev/e56c656a-df35-4ce6-9353-d9d6916c6730n%40googlegroups.com.

Daniel Beck

unread,
Nov 13, 2025, 1:16:32 PMNov 13
to jenkin...@googlegroups.com
On Wed, Nov 12, 2025 at 1:57 PM Tim Jacomb <timja...@gmail.com> wrote:
Happy to push it back a week or some, from a migration script PoV we have everything we need. Herve is planning a couple of improvements to make the issue processing script faster.

Last example migration:

What motivates this aggressive schedule?

I've yet to see a complete sample migration in which I haven't found problems with basic formatting or use cases within minutes. For example, https://github.com/jenkinsci/jep/blob/master/jep/238/README.adoc#how-do-i-find-issues-ive-reported-on-jira simply doesn't work. It has numerous false positive findings (as it seems to look for "reported", "by:" and username anywhere in the issue -- look for your own username, and the top 3 issues aren't reported by you), and wrapping it in quotes finds nothing.

Another problem is that none of the many copies of JENKINS-76266 in the latest import has correct formatting, which indicates code formatting imports remain broken, making messages like https://github.com/timja-org/jenkins-gh-issues-poc-11-06-a2/issues/375#issuecomment-3499805311 useless. https://github.com/jenkinsci/jep/blob/master/jep/238/README.adoc#the-description-doesnt-render-well-in-some-cases-what-gives is just not a good answer IMO. Would it be possible to at least attach a raw wikitext output inside a details block, so if something looks off, the correct version, even if unrendered, is quickly accessible?

I'd strongly prefer if content problems and common use cases would be addressed before scheduling the actual migration. This includes giving folks time (1-2 weeks at least) to review the final form of the migrated data and confirm that there are no substantial problems left, and that common use cases are supported.


CONFIDENTIALITY NOTICE: This email and any attachments contain confidential and proprietary information of CloudBees intended only for the named recipient(s). Unauthorized use or distribution is prohibited. If you received this in error, please notify the sender and delete this email.

Tim Jacomb

unread,
Nov 14, 2025, 11:42:52 AMNov 14
to jenkin...@googlegroups.com
> This includes giving folks time (1-2 weeks at least) to review the final form of the migrated data and confirm that there are no substantial problems left, and that common use cases are supported

To give people time to review the migration, the planned date is now Monday 24th November.

The latest migration is:

New features:
  • Raw HTML is in the description and comments
  • metadata available for searching reported by and commented on
  • Improved description export handling code blocks better and noformat
  • Avatars for comments
  • Jira commenter now archives issues and pins the comment

(I think that's the right link, Jira isn't loading for me right now)

> Another problem is that none of the many copies of JENKINS-76266 in the latest import has correct formatting


> I'd strongly prefer if content problems and common use cases would be addressed before scheduling the actual migration

All known content problems had been resolved (except for raw xml / html directly in the Jira).

> Would it be possible to at least attach a raw wikitext output inside a details block, so if something looks off, the correct version, even if unrendered, is quickly accessible

It's in the "originally reported by" section.

On Thu, 13 Nov 2025 at 18:16, 'Daniel Beck' via Jenkins Developers <jenkin...@googlegroups.com> wrote:


On Wed, Nov 12, 2025 at 1:57 PM Tim Jacomb <timja...@gmail.com> wrote:
Happy to push it back a week or some, from a migration script PoV we have everything we need. Herve is planning a couple of improvements to make the issue processing script faster.

Last example migration:

What motivates this aggressive schedule?

I've yet to see a complete sample migration in which I haven't found problems with basic formatting or use cases within minutes. For example, https://github.com/jenkinsci/jep/blob/master/jep/238/README.adoc#how-do-i-find-issues-ive-reported-on-jira simply doesn't work. It has numerous false positive findings (as it seems to look for "reported", "by:" and username anywhere in the issue -- look for your own username, and the top 3 issues aren't reported by you), and wrapping it in quotes finds nothing.

Another problem is that none of the many copies of JENKINS-76266 in the latest import has correct formatting, which indicates code formatting imports remain broken, making messages like https://github.com/timja-org/jenkins-gh-issues-poc-11-06-a2/issues/375#issuecomment-3499805311 useless. https://github.com/jenkinsci/jep/blob/master/jep/238/README.adoc#the-description-doesnt-render-well-in-some-cases-what-gives is just not a good answer IMO. Would it be possible to at least attach a raw wikitext output inside a details block, so if something looks off, the correct version, even if unrendered, is quickly accessible?

I'd strongly prefer if content problems and common use cases would be addressed before scheduling the actual migration.
 
.


CONFIDENTIALITY NOTICE: This email and any attachments contain confidential and proprietary information of CloudBees intended only for the named recipient(s). Unauthorized use or distribution is prohibited. If you received this in error, please notify the sender and delete this email.

--
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,
Nov 15, 2025, 1:05:27 PMNov 15
to jenkin...@googlegroups.com
Thanks, the descriptions in the most recent import look a lot better.

I cannot find any issues reported against the 'cli' component in Jira in your imports though. The 'cli' Jira component is tracking issues in the CLI, which is part of jenkinsci/jenkins. If this is intentional, it seems important enough to mention in the JEP.

Is there a test import of remoting issues we could review?
How are you going to handle issues with both 'core' and 'remoting' components (and similar overlaps)? Does one repo take precedence, e.g., only import into jenkinsci/jenkins, not jenkinsci/remoting? Or perhaps into remoting, it being the more narrowly scoped repo?

How are you going to update the changelog YAML format, generation and rendering in jenkins.io to account for the change in issue tracker? I cannot find any related PRs.

Tim Jacomb

unread,
Nov 15, 2025, 4:56:43 PMNov 15
to jenkin...@googlegroups.com
> I cannot find any issues reported against the 'cli' component in Jira in your imports though. The 'cli' Jira component is tracking issues in the CLI, which is part of jenkinsci/jenkins. If this is intentional, it seems important enough to mention in the JEP.

CLI issues will be in the next test migration, kicked off later tonight. Will be here: https://github.com/timja-org/jenkins-gh-issues-poc-11-15/issues

> How are you going to handle issues with both 'core' and 'remoting' components (and similar overlaps)?

They will all go to the jenkins repository if they have the core component. (handled by the fact we are archiving the issues as part of the migration which prevents them showing up in searches).

I'll do a bit of sweeping through the ones with multiple components that are open and see if any can be assigned better.

> Is there a test import of remoting issues we could review?

I was planning to do the other core components not going to the jenkins repo afterwards.
There's an export that was run here though: https://github.com/timja-org/remoting-gh-issues-poc-11-15/issues

(Note this will include multi component issues as the way they are excluded is by archiving them after migration)

> How are you going to update the changelog YAML format, generation and rendering in jenkins.io to account for the change in issue tracker? I cannot find any related PRs


--
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 visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2BhdAnVD_nJaesQf9n1o4tZSs-2bAFZKB_mm51k1PU1Zw%40mail.gmail.com.

Ullrich Hafner

unread,
Nov 15, 2025, 5:09:16 PMNov 15
to Jenkins Developers

> How are you going to handle issues with both 'core' and 'remoting' components (and similar overlaps)?

They will all go to the jenkins repository if they have the core component. (handled by the fact we are archiving the issues as part of the migration which prevents them showing up in searches).

I'll do a bit of sweeping through the ones with multiple components that are open and see if any can be assigned better.

Is the information about other components lost after the migration? E.g., JENKINS-76249 has core, credentials-plugin, ssh-credentials-plugin. 

What is the plan with cross project issues? Is it still possible to connect them somehow in the affected repositories? 
 


Tim Jacomb

unread,
Nov 16, 2025, 3:49:39 AMNov 16
to jenkin...@googlegroups.com
> Is the information about other components lost after the migration? E.g., JENKINS-76249 has core, credentials-plugin, ssh-credentials-plugin. 

That's in the latest import (since we've included cli issues and kept the context, other components will now be there too)

> What is the plan with cross project issues? Is it still possible to connect them somehow in the affected repositories? 

There's two types I can think of right now:
1. Epics with children that span repositories

Parent and child issues can be in different repositories, so one tracking issue can be filed in e.g. core for say Java EE 10 upgrade and then issues can be filed in the appropriate components and linked to the parent.

2. Issues that are filed potentially relating to multiple components.

These really don't work that well in Jenkins Jira as notification is driven off of assignee, they get lost very easily and are most often misfiled.
I went through most of the issues which had remoting and core components and the majority of them were not related to core.

If it's an issue in a plugin then it should be filed there first. If it's determined that its an issue in core then either:
* a targeted issue can be filed and a reference to the original issue in a comment or the description - I think the majority
* it can be moved - this should only be done if it was misfiled, e.g. if people are going to keep hitting the bug and think its the plugin it should probably stay so people can find their way. 

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

timja...@gmail.com

unread,
Nov 16, 2025, 8:28:46 AMNov 16
to Jenkins Developers
> What is the plan with cross project issues?

timja...@gmail.com

unread,
Nov 17, 2025, 11:55:49 AMNov 17
to Jenkins Developers
Hi all,


* Issues have been enabled on jenkinsci/jenkins

Thanks
Tim

Jenkins Developers

unread,
Nov 22, 2025, 8:35:37 AM (10 days ago) Nov 22
to Jenkins Developers
Thanks very much.  Could the migration tooling be extended to add the 'good first issue' label on migrated issues that have the Jira label 'newbie-friendly'?  We've used that to identify issues that are well suited to new contributors.

I also understand if that is not feasible.  It can be done after the migration if it doesn't fit into the migration schedule.

Mark Waite

Hervé

unread,
Nov 22, 2025, 10:51:39 AM (10 days ago) Nov 22
to Jenkins Developers

I'll see if we can replace this label directly during the import.

Note that all Jira labels are now stored as hidden refs in imported issues, those "newbie-friendly" issues can easily be filtered then their "newbie-friendly" label swapped by "good first issue" label via GitHub UI afterward.

Ex: https://github.com/timja-org/jenkins-gh-issues-poc-11-21/issues?q=is%3Aissue%20%22jira_label%3Dnewbie-friendly%22

Tim Jacomb

unread,
Nov 23, 2025, 9:41:41 AM (9 days ago) Nov 23
to jenkin...@googlegroups.com

To view this discussion visit https://groups.google.com/d/msgid/jenkinsci-dev/9e4b9323-3e24-42aa-8bbc-fb53b5d45b45n%40googlegroups.com.

Tim Jacomb

unread,
Nov 24, 2025, 2:48:58 AM (9 days ago) Nov 24
to jenkin...@googlegroups.com

Tim Jacomb

unread,
Nov 25, 2025, 3:11:26 AM (8 days ago) Nov 25
to jenkin...@googlegroups.com
The migration is close to done, all issues are imported.

I've paused updating the Jira issues as notifications are going out, which wasn't happening when we were testing.

We had planned to just send one bulk email.

Tim Jacomb

unread,
Nov 25, 2025, 3:33:14 PM (7 days ago) Nov 25
to jenkin...@googlegroups.com
The core / cli component migration is complete now.


Remaining work:
* Send notification to everyone who participated / watched a migrated issue
* Migration other core components, e.g. remoting.

Jira notifications have been re-enabled and the banner updated.


James Nord

unread,
Nov 27, 2025, 1:15:06 PM (5 days ago) Nov 27
to Jenkins Developers
Is there a way to lock the migrated issues without archiving them?

e.g. 

This is a pain as GH search searches the entire ticket (including the description) and I want to narrow the focus to just search the summary. (GH is currently giving me hundreds of results to trwal thorugh when I should be able to limit it to < 10).
Or is there some other GH search foo to only search the title of an issue?

(and yes this only would work for old issues, but this is an old issue I am looking for).

I am also concerned that the lack of decent search is likely to cause more duplicates to be filed, but then that is dependant on people searching before filing issues which may not actually happen, and this ship has sailed.

/James

James Nord

unread,
Nov 27, 2025, 1:19:41 PM (5 days ago) Nov 27
to Jenkins Developers
https://support.atlassian.com/jira/kb/how-to-make-jira-issues-read-only-using-workflow-properties/ perhaps?

Tim Jacomb

unread,
Nov 27, 2025, 3:14:17 PM (5 days ago) Nov 27
to jenkin...@googlegroups.com

CONFIDENTIALITY NOTICE: This email and any attachments contain confidential and proprietary information of CloudBees intended only for the named recipient(s). Unauthorized use or distribution is prohibited. If you received this in error, please notify the sender and delete this email.

--
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 visit https://groups.google.com/d/msgid/jenkinsci-dev/348b583b-a68b-4512-8189-288569c0b20cn%40googlegroups.com.

James Nord

unread,
Nov 27, 2025, 3:16:39 PM (5 days ago) Nov 27
to Jenkins Developers
That's perfect, thank Tim. 
The "in" keyword is completely new to me!

Reply all
Reply to author
Forward
0 new messages