如何将相应的编译单元(类文件...)链接到 JIRA 和 Bugzilla 问题

发布于 2024-12-04 03:33:03 字数 125 浏览 1 评论 0原文

我想从 Bugzilla 和 JIRA 获取开源项目的问题列表。对于每个问题,我想收集可能与该问题相关的相应编译单元(对于java项目、类/或接口文件)。

任何关于实现此功能的想法将不胜感激。

非常感谢!

I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.

Any idea on implementing this feature would be appreciated.

Many thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

装纯掩盖桑 2024-12-11 03:33:03

对于 JIRA,您可以使用一些开箱即用的解决方案。有关 JIRA 的操作方法,请参阅与源代码管理集成的文档。这仅适用于某些源代码控制系统,您应该了解哪些系统受支持。这为您提供了每个问题的变更集列表(例如 Subversion)。

另一种方法可能是通过自己与源代码控制系统的接口自行完成。必须具备以下先决条件:

  • 您的开发人员拥有工具来添加每个提交基础上的哪个提交处理哪个问题的信息。
  • 您有规则规定,每次只能针对一个问题对源进行更改。
  • 您能够解析从版本控制系统获得的附加信息,例如通过脚本或程序。

对于 Subversion 和 JIRA,它可以这样工作:

  1. 确保仅当 Subversion 提交消息包含至少一个 JIRA 票证号时才完成所有提交。您甚至可以通过预提交挂钩来确保
  2. 了解如何从颠覆日志中获取以下信息
    • 每个变更集的票证 ID(通过解析消息)
    • 每个更改集发生更改的文件
  3. 收集每个文件的所有票证。
  4. 以您喜欢的格式显示它们。

我认为这不太有用,因为每班的门票太细粒度了。也许您应该将文件映射到模块、子项目……并为它们收集票证。

根据您选择的工具,所有解决方案都会有所不同。 JIRA 和 Subversion 只是示例:-)

For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.

Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:

  • Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
  • You have rules that changes to the sources should all the time being done only for one issue at one time.
  • You are able to parse the additional information you will get from your version control system e.g. by a script or a program.

For Subversion and JIRA, it could work like that:

  1. Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
  2. Learn how to get the following information from the subversion log
    • The ticket IDs (by parsing the message) for each change set
    • The files that had changes for each change set
  3. Collect for each file all tickets.
  4. Show them in a format you like.

I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.

All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)

并安 2024-12-11 03:33:03

最好的方法是首先将问题跟踪系统与源代码控制集成。这意味着每当开发人员提交新更改时,它都会确定与此更改相关的问题集。此链接由您的问题跟踪系统管理,它可以向您显示在问题上下文中已更改的所有源文件、资源文件、配置文件。

此信息也可以通过该问题跟踪系统的 API 获得。

The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.

This info, will be available through the api of that issue tracking system as well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文