When I attempt to upload a patch created from a GIT repo via the command line (exactly as outlined in this article: https://confluence.atlassian.com/crucible/creating-patch-files-for-pre-commit-reviews-298977458.html), I get this error message: "Error adding patch: revision display name may not be null or empty."
I've tried creating patches both for the working copy changes, and a local commit containing the same changes. I found a question describing the same problem: https://community.atlassian.com/t5/Fisheye-Crucible-questions/not-able-to-upload-patch/qaq-p/775575
That question has no answers, so I must ask again. What should I do to resolve the problem?
Hi @Ivan Nenchovski,
Could you please share more details regarding the current setup and the patch here?
This is what I would like to collect to start investigating:
- the Fisheye version
- the full stack trace from the atlassian-fisheye-YYYY-MM-DD.log file when reproducing the issue
- if possible, the full content of the patch (maybe you can create a small sample one that can be shared here)
- the Git version used to create the patch
Could you also try to generate the patch by running the git diff command (instead of using the command line option)? What happens if you paste the content directly into the patch user interface dialog in Fisheye (instead of uploading the file)?
I'll post a similar reply to the other question to see if we can troubleshoot this in parallel.
Caterina - Atlassian
Apologies for the late reply. It took a while to navigate the corporate infrastructure. This is what I've gathered so far:
- The Fisheye/Crucible version is 4.4.0 Build:20170412122150 2017-04-12
- There is no stack trace from said log file or so I'm told. The file contained system events from hours before the error occurred. Unfortunately, I couldn't obtain the full log and have no further knowledge on its contents. Is there another log file that could contain something useful?
- I created the patch with Git 2.17.0 - 64-bit. The remote repository is actually BitBucket v4.10.1, if that's of any use.
- I already tried the git diff method and having just now tried to paste the contents of the patch, I can confirm there is no difference in behavior.
Below is the content of a sample patch. Though the userToAssignTo value has been redacted out of security concerns, we still receive the same error. Also, in the process of creating a sample patch, we noticed the problem appears only when the patch reflects changes on a file which has been committed and pushed to the remote repository; including new files works without a hitch.
Post Deployment Testing/tests/config/test_config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Post Deployment Testing/tests/config/test_config.json b/Post Deployment Testing/tests/config/test_config.json
index 93e6b7c..4321ae1 100644
--- a/Post Deployment Testing/tests/config/test_config.json
+++ b/Post Deployment Testing/tests/config/test_config.json
@@ -109,7 +109,7 @@
- "userToAssignTo": "cus_admin"
+ "userToAssignTo": "CUS_ADMIN"
Incident response is a team sport, and customer support is an integral part of any team. While Ops is working hard to solve the problem at hand, support is on the front lines communicating with custo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs