jira

Is it possible to create an issue in jira using REST api? I didn't find this in the documentation (no POST for issues), but I suspect it's possible. A wget or curl example would be nice. POST to this URL https://<JIRA_HOST>/rest/api/2/issue/ This data: { "fields": { "project": { "key": "<PROJECT_KEY>" }, "summary": "REST EXAMPLE", "description": "Creating an issue via REST API", "issuetype": { "name": "Bug" } } } In received answer will be ID and key of your ISSUE: {"id":"83336","key":"PROJECT_KEY-4","self":"https://<JIRA_HOST>/rest/api/2/issue/83336"} Don't forget about authorization. I used

I've been trying to find a way to update JIRA when I commit to github. It doesn't look like there are any service hooks to do it at github, but you never know, someone might have a ninja way, so I thought I'd ask. Kuf UPDATE For integrating with Bitbucket, GitHub and GitHub Enterprise, check out the following link: Linking Bitbucket and GitHub accounts to JIRA ORIGINAL POST JIRA GitHub Connector is deprecated: This plugin has been superseded by the JIRA DVCS Connector, which includes GitHub functionality. So to connect Jira to github use JIRA DVCS Connector for Bitbucket and GitHub : You can

09年到了现在这家公司，公司在项目管理上用的工具很多包括jira , TD ,SVN, twiki 等等， 但各自都很独立，例如需求在Jira里管理，测试用例在TD里管理，代码在SVN中管理，那么就面临一个问题如何把一个需求跟踪做到，需求录入开始，设计，开发，代码提交，测试分析，测试执行通过全流程的跟踪。 要解决这个问题就需要有一个平台能够把这些信息整合，统一跟踪管理。 带着这个思路我们在测试部门提供了建立UCM平台这个项目。 UCM 平台是通过数据库和SVN变更信息提取的方式抽取数据，在UCM平台中建立关系并进行信息整合。跟据测试部门中的资源情况，先进行了一个总体的预期规划，在进行分阶段执行。下面介绍一下总体规划。 先说一下数据准备要有哪些： 首先需求数据要获得需求编号，版本号，作者，日期，等信息，这些数据可以在jira数据库中直接读取。 其次是代码并更数据，这部些数据可以直接从SVN中抓取，需要进行SVNkit的二次开发。 （其实SVN有Jira插件的，可以继承到Jira界面，但是因为公司环境部署原因jira服务器无法访问内网中的SVN服务器，所以无法使用，我们做两者关联的原理是一样的——都是冲过CI事件的Comment信息中找issue ID 信息） 其次是测试用例数据的提取，这个数据可以重TD后台数据库中提取出来。如果用TestLink 也是可以提取的。

I've written below C# code to login to JIRA Rest API: var url = new Uri("http://localhost:8090/rest/auth/latest/session?os_username=tempusername&os_password=temppwd"); var request = WebRequest.Create(url) as HttpWebRequest; if (null == request) { return ""; } request.Method = "POST"; request.ContentType = "application/json"; request.ContentLength = 200; request.KeepAlive = false; using (var response = request.GetResponse() as HttpWebResponse) { } When I execute this, application just goes on running without returning any response. Please suggest if this is the right way of calling JIRA Login

We use Jira extensively in our project, but I often have a hard time finding issues, that I know, I have been working on earlier. Usually, if some case is reported, that seems familiar to something I have been working on in the past, but I don't remember exactly what and when. Usually, an issue is reported, then our scrum master assigns it to the developer, the developer fixes it (hopefully) and then passes it to the tester (yay, it works!). But then it is no longer assigned to me, and I have a hard finding old issues, that I remember vaguely. I thought, perhaps it is possible to see the

本文首发于： Jenkins 中文社区 原文链接 作者：Sushil Kumar 持续测试的那些事 持续测试究竟是什么？你又如何实现它呢？ 敏捷，DevOps 和持续交付已然存在于现今每个技术人员的词汇当中。我们都想要像硅谷里的巨头和初创公司一样，敏捷开发，快速发布软件，做出创新的产品。 向敏捷转型在多方面都已有总结，并且到了能被顺利实践的程度。然而，测试仍然是一个有思想困惑和实践挑战的领域。 当软件发布周期从以年、月缩短到以周、天为单位，或者更短时； 我们该如何重塑测试实践，以保证当软件发布到生产环境时能令用户满意， 而不是掉链子？ 鉴于大多数 DevOps 实践仍然把测试视为软件生产中最令人头疼的瓶颈，显然，这是一个常见的挑战。 持续测试就是答案，但持续测试究竟是什么？你又如何实现它呢？ 维基百科定义 持续测试 为「在软件交付流水线中执行自动化测试的过程，目的是为了获得关于预发布软件业务风险的即时反馈」。 但是这个定义缺少了本质，缺少了持续测试所示意的转变的量纲。 除了自动化是一个重要的部分以外， 持续测试 从根本上转变了测试， 它把线性过程中的时间点事件嵌入到整个过程当中去，作为基础贯穿于整个软件交付周期的所有活动中。 敏捷环境里持续测试的目标应该是「迭代内测试（in-sprint testing）」。 不管你的迭代是两周还是四周，目标都应该是完成迭代内所有类型的测试

更新于2019年8月13日 昨天下班后又把Jira生态圈回归了一下，自己实在打脸了，JIRA是有很牛逼之处的，只是我以为人家只是个bug记录系统。不了解却还瞎BB。脸打的疼。 很多人问我，缺陷管理工具，为什么不用jira？而去自己造轮子开发一款bug记录系统 缄默如我，原因众多。如果只是3-5分钟就能讲的请的时候，我会先列出什么糟点呢？ 1. 收费，一个人一个月的费用差不多要10美金，100个人的公司要100*10*12，即一年8万元钱，找一个人开发一个Bug系统，比如我这样的好学者，不要钱 2. bug的记录存储在atlassian公司，数据取不出来，你以后想根据自己的维度，去做统计和报表，将不方便 3. 使用不是很流畅，网速慢，忍不了 4. 填写一个Bug的时候，要填写的字段太多，不是很方便 5. Jira中支持增加字段，但是交互性不是很强 6. Bug系统，可以认为是测试平台中的一部分，Jira所在公司atlassian也提供了一些其他产品，比如用于文档协作的Confluence，用于IT服务台的Jira Service Desk，用于敏捷计划的Jira Align 但我们认为，一个测试生态中需要更多的功能，比如， 1）自动生成测试用例，自动构建测试数据，自动执行case等 2）文档协作，需要更强，比如将业务流用需求图/流程图画出来，可以展示给全team