利用Gitlab的Jira issue tracker实现Jira issue自动根据Gitlab commit/merge更新状态

  首先一个参考文档：http://git.jd.com/help/user/project/integrations/jira
  其次此文档中与我的jira版本和gitlab版本实际差异还是较大，记一下趟过的坑吧：

1. jira上的配置：
  我用的是jira7.3.8，配置用户组权限处和上文不一样，设置group权限是从管理->系统->安全->全局权限进去设置，而且没有显示有jira-core的，于是将gitlab-developers设成了[JIRA 管理员]的权限

2. Gitlab上的配置：
   1) Gitlab配置需有repo的master权限
   2) 配置的时候从integration进去，是点击Jira转进link，而不是点前面的电源开关的符号，本废在这上面竟然被block了一下-_-b
   3) JIRA API URL直接填与上面的Web URL一样就行
   4) Transition ID这个解释起来比较复杂。首先，用上文的方法去取，我得到的是这样的输出：
$  curl -s http://gitlab:gitlab@cloudjira.jd.com/rest/api/2/issue/TEST-3/transitions
{
"expand":"transitions",
"transitions":
[
{"id":"191",
"name":"on-going",
"to":
{"self":"http://cloudjira.jd.com/rest/api/2/status/10301",
"description":"",
"iconUrl":"http://cloudjira.jd.com/images/icons/statuses/generic.png",
"name":"Develope",
"id":"10301",
"statusCategory":
{"self":"http://cloudjira.jd.com/rest/api/2/statuscategory/4",
"id":4,
"key":"indeterminate",
"colorName":"yellow",
"name":"处理中"
}
}
},
{"id":"51",
"name":"testing",
"to":
{"self":"http://cloudjira.jd.com/rest/api/2/status/10300",
"description":"开发完成转测试",
"iconUrl":"http://cloudjira.jd.com/images/icons/statuses/generic.png",
"name":"Test",
"id":"10300",
"statusCategory":
{"self":"http://cloudjira.jd.com/rest/api/2/statuscategory/4",
"id":4,
"key":"indeterminate",
"colorName":"yellow",
"name":"处理中"
}
}
},
{"id":"131",
"name":"no more develop",
"to":
{"self":"http://cloudjira.jd.com/rest/api/2/status/10027",
"description":"",
"iconUrl":"http://cloudjira.jd.com/images/icons/status_generic.gif",
"name":"Cancelled",
"id":"10027",
"statusCategory":
{"self":"http://cloudjira.jd.com/rest/api/2/statuscategory/3",
"id":3,
"key":"done",
"colorName":"green",
"name":"完成"
}
}
}
]
}
   完全看不明白该用191,51,131的哪个啊！好在看description可以看出来这是这个问题TEST-3当前的状态，于是对比一下
   于是明白了，191"on-going"，51"testing"和131"no more develop"分别是根据此问题TEST-3配适的workflow，在当前状态可以改变状态的对应动作：
   所以我们明白了：如果想要实现对特定状态的跃迁，那么transition id就选那个对应的id；如果想实现不论哪种状态都可以通过gitlab添加jira更新，那么就可以如上面我这个workflow的例子一样，在workflow里添加一个从自己到自己的状态"on-going"，然后把transition id设为这个的id，那么在gitlab里只要commit时附注写了这个id，那么就可以实现所有的状态下均可用此id了。

   具体可以实现两种关联：
1. Referencing JIRA Issues：这个只要commit的时候，comments里有jira issue的号就可以，比如：
% git commit -am "Closes JIRASYSTEM-10"
% git push origin jira-optim # 因为commit只到本地，须push到gitlab上才会触发tracker
注意：jira号对大小写敏感，写成jirasystem-10是没用的
这时Jira里提及的jira issue比如JIRASYSTEM-10就会自动更新状态与注释
 2. Closing JIRA Issues：这个需要在commit的时候注释里写上触发关闭的三种关键字之一：这其实是实现对特定状态的跃迁，所以transition id也应该设为对应close状态的那个id
  • Resolves JIRASYSTEM-10
  • Closes JIRASYSTEM-10
  • Fixes JIRASYSTEM-10
我试的是Closes：
$ git commit -am "Closes JIRASYSTEM-10"
$ git push origin jira-optim 
然后在Gitlab里合并时，也在comments里写触发关键字
这里的“Jira optim”是merge request的标题，"Closes JIRASYSTEM-10"是mr的注释
然后再看jira，就会看到对应issue被自动关闭的状态改变信息：
如上述第一张附图中被中横线划掉的部分

    总结一下，transition id的选取，与配适的workflow里的设定紧密相关，与workflow里设定的状态跃迁紧密相关，必须有对应的、可跃迁的状态改变，才可能通过gitlab触发jira自动更新。这一点一定要弄清楚。

评论

发表评论

此博客中的热门博文

Windows上调试C/C++程序时自动产生coredump的设置方法

1. 安装Windows debug tool，全部使用默认安装选项即可 搜索 Windbgx86_v6.12.2.633.1395371577.msi 并下载 或者也可到微软官网上下载windows调试工具，windbg也在其中： https://developer.microsoft.com/zh-cn/windows/hardware/download-windbg 注：此版本为32位版，但在32位和64位操作系统上均能使用 2. 将windbg.exe设置为默认debugger工具： 起一个cmd，进入windbg的安装目录，默认是C:\Program Files (x86)\Debugging Tools for Windows (x86)\ 然后执行C:> windbg.exe -I 注意-I必须大写 然后windbg的程序主窗口会自动打开，并且弹出一条信息windbg已经被成功设置为默认的debugger云云... 点确定后窗口会自动关闭，至此设置成功 3. 创建一个存放coredump文件的目录 D:\Dump 4. 修改系统注册表，捕获异常崩溃时自动产生Coredump文件：   1) regedit打开注册表，找到注册表项，先备份：      64位系统： HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug      32位系统： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug   2) 修改Auto的值，原来的默认值为0不启动debugger，修改为1默认启动debugger   3) 修改Debugger的值，如果上述第2步执行成功，那么此处的值应该已经被改为了"C:\Program Files (x86)\Debugging Tools for Windows (x86)\windbg.exe" -p %ld -e %ld -g      现在需要将其修改为导出并保存co...
阅读全文

go用xorm去update数据库的一个坑

    最近写API服务比较多，一般试验性质的用python flask简单又快，需要稍微考虑点儿并发性能的，那还是用go来写咯。API服务一般都要落盘写库，随便选了个xorm来写mysql数据库。     但是最近碰到一个有点儿奇怪的现象，调用端报告偶有数据没有更新的现象。回头去查代码，写库这段逻辑如下：  if _, err = session.Where("col1 = ?", d.col1).Update(d); err != nil {     glog.Infof("has result col1:%s updated!", d.col1)     return }     一眼就能看明白的一个调用，看不出有啥毛病啊-_-b     试图重现也没能重现，于是只能加debug log以图能保存下次发生时的事发现场。结果过了一个月果然又出现了。确实是这段代码更新表中数据时出错了。     后来搜xorm文档时发现了这么一个Q&A: https://www.kancloud.cn/kancloud/xorm-manual-zh-cn/56018 我的struct里面包含bool类型，为什么它不能作为条件也没法用Update更新？ 答：默认bool类型因为无法判断是否为空，所以不会自动作为条件也不会作为Update的内容。可以使用UseBool函数，也可以使用Cols函数 engine . Cols ( "bool_field" ) . Update ( & Struct { BoolField : true } ) // UPDATE struct SET bool_field = true       深受启发啊！我出问题的数据虽然不是bool，但是0！于是又去查了下文档，发现xorm的帮助文档在一个角落里果然提到了bool false, int 0, 空nil都 默认不会更新 ！好坑啊！这种update默认方式的设计简直是反人类啊！    ...
阅读全文