I'm a bit of a novice using JIRA and I don't know why this is happening. Lately, whenever I mark an issue as "Done", the system won't update as it being "Closed" but rather keep them as "Unresolved". Why would this happen? I don't know what information I must provide to solve this issue, except that I'm using JIRA 6.1.3, self-hosted, and no extra plugins.
That issue is neither fully resolved nor necessarily related, but you might want to check into Fix apparent data integrity violation with closed issues not actually being closed (JRA-34222), in particular Andreas Knecht's comment, summarizing potential race conditions during workflow changes:
Yeah so bulk editing while doing workflow changes definitely has the potential to cause this sort of a problem. JIRA doesn't really lock down a project while doing workflow migrations AFAIK so this kind of thing can always happen if concurrent operations are happening during a migration.
It's a complicated problem with an even more complicated solution. For some reading on an analysis we did ages ago see [not accessible link to 'Concurrency+Problems+in+JIRA']. Also [not accessible link to 'Concurrency+bug']. It's a known problem, but the solution has huge performance implications for JIRA and will take considerable effort to implement and test.
The last comment from a Cisco employee seems to confirm Andreas' summary that this might be a generally applicable issue with JIRA for the time being:
JIRA 5.2.8 we have been having an issue like this for months. I can
not view it, but see also: JSP-161469
Recent investigation has correlated "Tried to reopen the IndexReader,
but it threw AlreadyClosedException." message as closely following the
execution of Jython scripts. [...]
Possible Remedy/Workaround
While not addressing the root cause, you an see from the screenshot attached by Michael Knight that Atlassian seems to have been able to fix the integrity issue at hand by Using the Database Integrity Checker:
This aptly named JIRA feature is useful in a number of situations, e.g.
Before migrating a project to a new workflow [emphasis mine]
An external program is modifying JIRA's database
Troubleshooting a server crash
Using such a tool is obviously not without risks itself, so please note that Atlassian strongly recommend[s] taking a backup of your data before correcting any data inconsistencies accordingly
Good luck!
Here is a very good confluence answer that explains why this happens and a few workarounds Confluence Answer to Done issues as Unresolved
Related
This is sort of an open-ended question/request (hope that's allowed).
On my team we are using Karate API testing for our project, which we love. The tests are easy to write and fairly understandable to people without coding backgrounds. The biggest problem we're facing is that these API tests have some inherent degree of flakiness (since the code we're testing makes calls to other systems). When running the tests locally on my machine, it's easy to see where the test failed. However, we're also using a Jenkins pipeline, and when the tests fail in Jenkins it's difficult to see why/how they failed. By default we get a message like this:
com.company.api.OurKarateTests > [crossdock] Find Crossdock Location.[1:7] LPN is invalid FAILED
com.intuit.karate.exception.KarateException
Basically all this tells us is the file name and starting line of the scenario that failed. We do have our pipeline set up so that we can pass in a debug flag and get more information. There are two problems with this however; one is that you have to remember to put in this flag in every commit you want to see info on; the other is that we go from having not enough information to too much (reading through a 24MB file of the whole build).
What I'm looking for is suggestions on how to improve this process, preferably without making changes to the Jenkins pipeline (another team manages this, and it will likely take a long time). Though if changing the pipeline is the only way to do this, I'd like to know that. I'm willing to "think outside the box" and entertain unorthodox solutions (like, posting to a slack integration).
We're currently on Karate version 0.9.3, but I will probably plan to upgrade to 0.9.5 as part of this effort. I've read a bit about the changes. Would the "ExecutionHook" thing be a good way to do this? I will be experimenting with this on my own a bit.
Have other teams/devs faced this issue? What were your solutions? Again we really love Karate, just struggling with the integration of it to Jenkins.
Aren't you using the Cucumber Reporting library as described here: https://github.com/intuit/karate/tree/master/karate-demo#example-report
If you do - you will get an HTML report with all traffic (and anything you print) in-line with the test-steps, and of-course error traces, and most teams find this sufficient for build troubleshooting, there is no need to dig through logs.
Do try upgrade as well, because we keep trying to improve the usefulness of the logs, and you may see improvements if you had failed in a JS block or karate-config.js.
Else, yes the ExecutionHook would be a good thing to explore - but I would be really surprised if the HTML report does not give you what you need.
Our company want to implement an bug tracker, which will be usable for our partners. Currently we are using TFS as our source control and ALM system. Now i'm confused, how to combine these two systems, because in the TFS we have our product versions and work items (maybe also bugs). But when we start using Redmine, we don't have them in the TFS any more, or is there a way, to use them together?
I could not find any plugins or something similar.
Maybe some one has experiances in the area, thank you!
First, things reported by customers are not bugs in the engineering sence. They are defects that may or may not be bugs.
Specifically in TFS a bug work item is used to represent the meta data of a failing test or exception.
To integrate you will either have to roll your own or buy a tool. I recommend talking to TaskTop as the best work item tracking integration tool...
With all due respect, the accepted answer has misleading statements.
First, things reported by customers are not bugs in the engineering
sence. They are defects that may or may not be bugs.
Even when we talk about TFS/Redmine and the like, the concept of a bug is very different from what is being expressed here.
According to ISTQB (and other qualification boards related to software quality) there is a difference between an Error, a Failure, and a Defect.
Let me explain each concept:
Error: is produced by a human being's actions (for now :) ) it's existence may or may not be detected and may or may not be classified as a software Defect
Failure: is how an Error can be detected while using the Application Under Test (i.e. error messages, data inconsistency, unexpected behavior, etc). A Failure may or may not be detected, but most often ends up being classified as a Defect.
Defect: is the documented description of a software Failure. It usually includes actual software behavior and expected software behavior. More and varied information can be included as well (i.e. software version, environment, etc)
Now what is a "Bug"??
"Bug", as a term, is a software testing slang that dates back to the late 40's.
Check this out:
http://www.computerhistory.org/tdih/September/9/
Taking all the aforementioned, we can say that the Work Items in TFS and Issues in Redmine both have a "Bug" category that refer to work items that allow Defect management actions.
In conclusion, whether or not the unexpected behavior was found by a customer does not change the fact that a "Defect" is a "Defect", and therefore a "Bug" is a "Bug".
eJabberd Version 2.1.13
We set up an ejabberd server as part of our app about a year ago (Oct 2013). Shortly after going live we found issues with ejabberd messages locking up when we reached about 1,200 people online (not all of them were necessarily sending messages).
Following much head scratching the issue was traced to a known (unresolved) bug here: https://support.process-one.net/browse/EJAB-1583
In short, an ODBC timeout of 5secs causes a total messaging downtime of 150 seconds ... this rules out the easy fix of extending the timeout because a 7 sec timeout turns into 210 second downtime etc.
I've tried a lot of "experts" to try to find a solution, but it became apparent quite quickly that there are not many experts around. I'm wondering if anyone has encountered this problem and found a fix, or found ways of reducing the occurances.
The obvious answer is "upgrade", but this is a non-trivial exercise, and our key developer was poached about a year ago (we no longer have the internal expertise necessary).
In summary the questions are:
Are there any recommended configuration settings we can use to reduce this issue?
Does anyone know a genuine ejabbered expert they could refer us to?
Many thanks,
David
Not sure how to solve the issue with ODBC, especially not trough any settings that would refer to this. What you might need is custom patch, or actual code upgrade.
Always thought that process-one offers some services regarding ejabberd. Especially since it is theirs product.
I could also recommend Erlang Solutions which offers consulting, both in ejabberd and MongooseIM (their custom fork of ejabberd focused on performance).
And if you looking for someone full time postin offer at Erlang Central might be a good idea.
With TFS2010 using the "MSF for Agile Software Development v5" process template, I'm having some difficulty in understanding exactly what an Issue is. The most specific documentation I've been able to find is this. Is an Issue a higher-level item for which we will probably generate a Bug for after some investigation in code/requirements? Or is an Issue something different than a Bug because it has not actually a mistake in code but is more of a critical oversight in design (for example, there was never an attempt to create a datepicker for all date fields and this is a UX issue but not really a bug) and therefore a change request of sorts? Or is it something different?
I think Issue == Impediment
An issue is a problem. After investigation it could become a bug in the software, or a task to change the process and code that supports it.
Clarification/summary for the question -- we're looking for:
a hosted bug tracking system,
that is as convenient to use as lighthouse/github/launchpad,
can deal with attachments,
integrates email notifications and operations (implies operations in commit messages),
has a script-friendly API,
allows anonymous bug reports, or ones with an email but that do not require setting up an account for submission.
Lighthouse is close but fails on the last point, launchpad is similar, github also doesn't handle attachments. Tender is great for the last point, but fails as a general bug tracking system (and it looks like its open-source version will be limited to basically being a forum).
We looked into a number of applications to install and setup -- but with this range of requirements, they are always coming with a huge cost in terms of investing time in setting up and maintaining a working system.
In our (open-source) project we have been using Gnats for a really long time. It doing what it was designed to do fine, but that's getting to be pretty inconvenient: it's no longer maintained, has features that we never use, and lack features that we'd want to use... It doesn't deal with attachments, has no easy way to perform actions via emails, no integration with commit messages, and a web interface that was designed for 90s browsers. So I've been looking around in an attempt to find something that could replace it, hopefully some hosted solution to avoid the setup/maintenance hassle.
Probably the most impressive tool that I've seen is lighthouse: it has a very nice and practical interface, properly deals with attachments, controllable via emails, and can respond to commands in commit messages. But... It doesn't have any sane way to submit a bug anonymously -- and that's a major requirement, since we need any random user to be able to submit bugs through our IDE. (It seems that there is a possible hack to forward an email faking the From field, but that doesn't work very well -- specifically, the reporter should be included in the followup email exchange.) On the other side, there is the related tender tool, which is very good in that area, but is very basic otherwise -- too basic to serve as a bug tracking system.
There's a whole bunch of other sites that I've tried -- it seems that all of them require submitters to have an account, so they don't work well for our needs; as well as being limited in various other ways (don't deal with attachments, no good email integration, etc etc). It doesn't help that the meta-descriptions of these sites is usually pretty obscure: it took me hours to just figure out what tender/lighthouse are and how they're related, and no site mentions its inability to receive bug reports without registration. (I'm looking only at open-source-friendly sites, since we don't have any kind of budget for such things.)
There's also the option of installing some system locally, but bug tracking systems tend to be monsters that I'd like to avoid configuring and maintaining, if possible.
So the question is: is there anything obvious that I'm missing? Or to make it more concrete: is there a good comparison page somewhere that lays out popular options and their respective features explicitly?
JIRA is free for open source projects. It's far more user friendly than trac and bugzilla, and allows anonymous submissions and plugins. Unfortunately you'll need to host it on your own server, but from personal experience I can tell you that all you need to do is install a database (it can run without; but that's not a good idea) and it basically maintains itself.
Also is there a particular reason why Google Code or Sourceforge issue tracking tools wouldn't work? You don't need to use all their services if you don't want, you could use them purely for issue tracking.
Did you try trac? It is used by many open source projects.
FogBugz is one option. They'll host or you can run it yourself. My company looked at it but ... political considerations ... meant it is not viable here.
Have you looked at this Comparison of issue tracking systems on Wikipedia?
I have also found fixx, by hedgehoglab. Apparently it has the features that you care more:
Get things done
fixx has an intuitive interface to enable quick bug
reporting. Filling in a bug report is
as easy as sending e-mail.
Ability to add multiple attachments to issues allowing you
to attach screenshots and manage
documents related to issues.
Clever notification options to keep relevant people informed while
preventing issue tracker spam.
Also:
It has an open REST API.
I see that you are using Subversion as SCM. There is a Subversion integration with fixx.
Its unique installation requirement is Sun JDK 1.5.0.
It seems free for Open Source Projects and an hosted version is "Coming soon".
Note that I have never used it, so I cannot give any recommendation.
The open source BugTracker.NET has support for the following areas that are giving you problems:
Attachments
Guest login
Email notifications
SVN commit integration
I found it easy to set up, maintain, and tweak. Of course, you might think otherwise if you are not familiar with .NET and have a Windows server available.
You might look at Unfuddle. They do allow an API for the submission of tickets and have your other points covered including attachments.
Take a look at repositoryhosting.com They have ready made solution with trac / svn / git, for you. Comes with all kinds of bells and whitsles, such as Agilo plug-in and auotomatic backup to the amazon S3 bucket of your choice.
The prices are very reasonable.
Also, jumboxes offers a Trac / SVN virtual appliance that you can host in your own environment.
Redmine is a good open source option. You can check an online demo and a list of features.
It's not hosted though. But it's an interesting option.
And you can always check a list of different open source bug tracking alternatives
I've used ZenDesk in the past and it was rather hassle free.
In addition it has an api: http://www.zendesk.com/api.
Moreover I KNOW it can CC whosoever you want it to whenever anything happens.
We too are looking for a new solution.
At present we're using FogBugz, which is painfully slow.
We need our customers to be able to log bugs via email. Tender looks perfect, with the exception that it doesn't have any obviously usable ID fields that we can pass around. Is there a plugin or similar? I could knock up a browser extension to "goto bug id [whatever]" but that seems kludgy for what should surely be a core feature?