Import issues from Bugzilla #3754

New Issue

GiteaMirror · 2025-11-02T05:24:12-06:00

GiteaMirror commented

2025-11-02 05:24:12 -06:00

Originally created by @argv-minus-one on GitHub (Aug 8, 2019).

Gitea version: 1.9.0
Git version: 2.20.1
Operating system: Debian Linux amd64
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

Please add support for importing issues from Bugzilla.

Note that Bugzilla is often used to track issues for many different projects in one place, whereas Gitea/GitHub-style issue tracking has a separate issue tracker for each project. A Gitea importer would need to be able to select which Bugzilla “product” to import issues for.

Originally created by @argv-minus-one on GitHub (Aug 8, 2019). - Gitea version: 1.9.0 - Git version: 2.20.1 - Operating system: Debian Linux amd64 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description Please add support for importing issues from Bugzilla. Note that Bugzilla is often used to track issues for many different projects in one place, whereas Gitea/GitHub-style issue tracking has a separate issue tracker for each project. A Gitea importer would need to be able to select which Bugzilla “product” to import issues for.

GiteaMirror added the type/proposal label 2025-11-02 05:24:12 -06:00

GiteaMirror commented

2025-11-02 05:24:13 -06:00

@argv-minus-one commented on GitHub (Aug 8, 2019):

It would also be preferable if Gitea could import from Bugzilla XML output, without contacting a Bugzilla instance directly. That way, Gitea won't need to deal with authenticating itself to Bugzilla, which may require a client certificate, Kerberos/Active Directory ticket, or the like.

@argv-minus-one commented on GitHub (Aug 8, 2019): It would also be preferable if Gitea could import from Bugzilla XML output, without contacting a Bugzilla instance directly. That way, Gitea won't need to deal with authenticating itself to Bugzilla, which may require a client certificate, Kerberos/Active Directory ticket, or the like.

GiteaMirror commented

2025-11-02 05:24:13 -06:00

@mrsdizzie commented on GitHub (Aug 9, 2019):

I think this would be pretty low priority if being honest, as most migrations are centered around github at the moment (and in the future probably similar services with similar APIs).

If you are looking to do this yourself, you could probably try and script it from the BugZilla XML export. This is an older script that took data from BugZilla and put it into Github.

https://github.com/erikmd/github-issues-import-api-tools/blob/master/attic/bugzilla2github

And perhaps some more information here:

https://www.theozimmermann.net/2017/10/bugzilla-to-github/

As a starting point for how somebody else did something similar

@mrsdizzie commented on GitHub (Aug 9, 2019): I think this would be pretty low priority if being honest, as most migrations are centered around github at the moment (and in the future probably similar services with similar APIs). If you are looking to do this yourself, you could probably try and script it from the BugZilla XML export. This is an older script that took data from BugZilla and put it into Github. https://github.com/erikmd/github-issues-import-api-tools/blob/master/attic/bugzilla2github And perhaps some more information here: https://www.theozimmermann.net/2017/10/bugzilla-to-github/ As a starting point for how somebody else did something similar

GiteaMirror commented

2025-11-02 05:24:13 -06:00

@argv-minus-one commented on GitHub (Aug 9, 2019):

@mrsdizzie I can indeed do that, except that there's currently no way in the API to preserve the issue numbers, and @lunny thinks it would be a bad idea to add a way, because issue migration should be built into Gitea instead. That's why I opened this issue.

As you say, Gitea's migration code seems designed for migrating Git repositories and associated data from GitHub-like sites. It would need a pretty major redesign to handle migrating anything else, such as issues from a separate issue tracker like Bugzilla. That's why I posted #7790: it would be a much simpler change, and allow people like me to write external issue-migration tools without having to make such drastic changes to Gitea itself.

With you apparently disagreeing with @lunny, I'm now at a loss as to what to do. Should I insert issues through Gitea's API and then change the issue numbers (with UPDATE issue SET `index` = ? WHERE `id` = ?) in the database directly? That seems to work, but will it break anything?

@argv-minus-one commented on GitHub (Aug 9, 2019): @mrsdizzie I can indeed do that, except that [there's currently no way in the API to preserve the issue numbers](https://github.com/go-gitea/gitea/issues/7790), and @lunny [thinks it would be a bad idea to add a way, because issue migration should be built into Gitea instead](https://github.com/go-gitea/gitea/issues/7790#issuecomment-519553855). That's why I opened this issue. As you say, Gitea's migration code seems designed for migrating Git repositories and associated data from GitHub-like sites. It would need a pretty major redesign to handle migrating anything else, such as issues from a separate issue tracker like Bugzilla. That's why I posted #7790: it would be a much simpler change, and allow people like me to write external issue-migration tools without having to make such drastic changes to Gitea itself. With you apparently disagreeing with @lunny, I'm now at a loss as to what to do. Should I insert issues through Gitea's API and then change the issue numbers (with ``UPDATE issue SET `index` = ? WHERE `id` = ?``) in the database directly? That seems to work, but will it break anything?

GiteaMirror commented

2025-11-02 05:24:13 -06:00

@mrsdizzie commented on GitHub (Aug 9, 2019):

I don't disagree with Lunny or have any particular opinion other than I wouldn't expect somebody else to add this migration code to Gitea anytime soon if you were hoping the issue would result in that.

Given that I was just pointing to a script of somebody who did something similar with Github which has the same limitations on not allowing setting an issue number via API.

@mrsdizzie commented on GitHub (Aug 9, 2019): I don't disagree with Lunny or have any particular opinion other than I wouldn't expect somebody else to add this migration code to Gitea anytime soon if you were hoping the issue would result in that. Given that I was just pointing to a script of somebody who did something similar with Github which has the same limitations on not allowing setting an issue number via API.

GiteaMirror commented

2025-11-02 05:24:13 -06:00

@guillep2k commented on GitHub (Aug 10, 2019):

Have you checked the "external issue tracker" option? I don't know what it does, but sounds interesting:

(Available at Repository Settings)

@guillep2k commented on GitHub (Aug 10, 2019): Have you checked the "external issue tracker" option? I don't know what it does, but sounds interesting: ![image](https://user-images.githubusercontent.com/18600385/62817144-1cdeb280-bb08-11e9-8df8-744d220c73d2.png) (Available at Repository Settings)

GiteaMirror commented

2025-11-02 05:24:14 -06:00

@argv-minus-one commented on GitHub (Aug 11, 2019):

@mrsdizzie Ok, fair enough. Would you happen to know if changing the issue numbers in the database after they're created (with the API) will break anything?

@guillep2k Yes, I saw that. That is an option, but I was hoping to migrate the issues into Gitea, because Bugzilla is rather slow and much less user-friendly than Gitea.

@argv-minus-one commented on GitHub (Aug 11, 2019): @mrsdizzie Ok, fair enough. Would you happen to know if changing the issue numbers in the database after they're created (with the API) will break anything? @guillep2k Yes, I saw that. That is an option, but I was hoping to migrate the issues into Gitea, because Bugzilla is rather slow and much less user-friendly than Gitea.

GiteaMirror commented

2025-11-02 05:24:14 -06:00

@guillep2k commented on GitHub (Aug 11, 2019):

@mrsdizzie Ok, fair enough. Would you happen to know if changing the issue numbers in the database after they're created (with the API) will break anything?

@argv-minus-one You need to update all the other related tables (attachment, issue_assignees, issue_watch, issue_dependency, issue_user, reaction, stopwatch, tracked_time, pull, review) to reflect the changes. But you'll probably have no rows in many of them if you've just created the issues. Disclaimer: I've just made a crude search through the source code to get the list; it may not be complete.

@guillep2k commented on GitHub (Aug 11, 2019): > > > @mrsdizzie Ok, fair enough. Would you happen to know if changing the issue numbers in the database after they're created (with the API) will break anything? > @argv-minus-one You need to update all the other related tables (`attachment`, `issue_assignees`, `issue_watch`, `issue_dependency`, `issue_user`, `reaction`, `stopwatch`, `tracked_time`, `pull`, `review`) to reflect the changes. But you'll probably have no rows in many of them if you've just created the issues. Disclaimer: I've just made a crude search through the source code to get the list; it may not be complete.

GiteaMirror commented

2025-11-02 05:24:14 -06:00

@jpicht commented on GitHub (Aug 11, 2019):

@argv-minus-one Two things:

Do you have an example of a Bugzilla XML file?
Would it be useful solution for you to only be able to import the XML while also importing the repository via migrations?

@jpicht commented on GitHub (Aug 11, 2019): @argv-minus-one Two things: - Do you have an example of a Bugzilla XML file? - Would it be useful solution for you to only be able to import the XML while also importing the repository via migrations?

GiteaMirror commented

2025-11-02 05:24:14 -06:00

@argv-minus-one commented on GitHub (Aug 13, 2019):

@jpicht

Do you have an example of a Bugzilla XML file?

Here's one from Mozilla's Bugzilla instance.

Here's the XML DTD from Mozilla's Bugzilla instance. Note that the DTD varies from instance to instance, because it reflects whatever custom fields are configured in the Bugzilla instance. Here's a Gist containing the DTD from my Bugzilla instance, which doesn't have any custom fields configured.

Would it be useful solution for you to only be able to import the XML while also importing the repository via migrations?

Yes.

I'd prefer to be able to upload the XML from my browser, instead of Gitea pulling it directly from a running Bugzilla instance, for two reasons:

I need to edit the comments in Bugzilla. Besides Bugzilla, I am also preparing to migrate from Mercurial to Git, and some of the comments in Bugzilla talk about Mercurial commit identifiers. These need to be rewritten to the corresponding Git commit identifiers, and the simplest way to do that is by editing the XML before handing it off to Gitea.
In my Bugzilla instance, user names are email addresses, and that's what appears in the XML. I need to rewrite them to Gitea user names. Again, the simplest way to do that is by editing the XML.

In the longer term, it would be ideal if Gitea could migrate issues (and perhaps other kinds of data) into existing repositories as well. However, I understand that Gitea's current design doesn't allow for this.

@argv-minus-one commented on GitHub (Aug 13, 2019): @jpicht >* Do you have an example of a Bugzilla XML file? [Here's one from Mozilla's Bugzilla instance.](https://bugzilla.mozilla.org/show_bug.cgi?ctype=xml&id=101) [Here's the XML DTD from Mozilla's Bugzilla instance.](https://bugzilla.mozilla.org/page.cgi?id=bugzilla.dtd) Note that the DTD varies from instance to instance, because it reflects whatever custom fields are configured in the Bugzilla instance. [Here's a Gist containing the DTD from my Bugzilla instance](https://gist.github.com/argv-minus-one/ebbab372257bb9cb948970a44872470c), which doesn't have any custom fields configured. >* Would it be useful solution for you to only be able to import the XML while also importing the repository via migrations? Yes. I'd prefer to be able to upload the XML from my browser, instead of Gitea pulling it directly from a running Bugzilla instance, for two reasons: 1. I need to edit the comments in Bugzilla. Besides Bugzilla, I am also preparing to migrate from Mercurial to Git, and some of the comments in Bugzilla talk about Mercurial commit identifiers. These need to be rewritten to the corresponding Git commit identifiers, and the simplest way to do that is by editing the XML before handing it off to Gitea. 2. In my Bugzilla instance, user names are email addresses, and that's what appears in the XML. I need to rewrite them to Gitea user names. Again, the simplest way to do that is by editing the XML. In the longer term, it would be ideal if Gitea could migrate issues (and perhaps other kinds of data) into existing repositories as well. However, I understand that Gitea's current design doesn't allow for this.

GiteaMirror referenced this issue

2025-11-02 12:25:36 -06:00

[PR #3754] [MERGED] Enhance healthcheck for database connectivity #17070

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3754