I have a workflow that that runs to update the status of a Case record to Resolved. However, the workflow gets put into status 'waiting' and contains a generic error message. When looking at the system job message it says:
This has worked on another system (as all I am doing is updating a status) so I assume it has something to do with the customizations in place.
Has anyone else ever come across this and how did you resolve it?
Thanks in advance
UPDATE:
I have created a new organisation to test out any possible solutions and to narrow down what might be happening.
I created a workflow on the blank organisation and a test case record to try it out on. It worked fine as expected.
I then imported the customizations that are on my customers system. Did the same again and it worked fine.
I then created a new case record and tried the original workflow, this did not work.
I then added a workflow that does the same as the first workflow and tried it on the pre customizations record, it worked.
I then tried the new workflow on the new record and once again this did not work.
It is therefore appearing that the workflows are not working on any records post customization import.
Has anyone come across this before, and what steps were taken to resolve?
Thanks again
If you have the possibility to look at the registered plugins, then search for a plugin registered on the message SetState or SetStateDynamicEntity for the entity case (incident).
I assume there is a plugin which fails in your case. This is the reason for your error message.
Related
I'm on an Enterprise License and for some unknown reason, I can't star any repo or file. When I click on Star, the following message appears: You can't perform that action at this time.
I haven't been able to find resource online to solve this issue. Has anyone ran into this scenario before?
Ok so I found a way to make it work. I created a list and then stared the repo that I wanted to that list. It is a strange case because I didn't have to do it this way before on other accounts. However, this solves it for me. Just wanted to post the answer in case someone else runs into similar scenario.
The organization I am with has transitioned to Azure DevOps for source control and for Sprint Management. I am responsible for investigating moving the organization to Azure DevOps for testing off of another solution. There is one question I have received from multiple people after doing some demonstrations that I have not been able to get an answer on.
What I have been asked if the system can do, is that when a Bug is entered during a Test Execution, for it to automatically have the User Story that the script is related to be set as a parent.
For example:
If I have User Story 123, which has a Tested By relationship to Test Case Test1. Test Case Test1 is in Test Plan ABC, which was created with the Area Path of my team and Iteration of the current Iteration. If I create a Bug while executing Test1 (in a Test Suite in Test Plan ABC), it currently adds the Bug to the current Iteration, but under an Unparented story. We would like to see that bug automatically appear under User Story 123.
Is this possible? Thanks for any information regarding this.
I think you can use Create work item task behind your test task in your build/release pipeline.
In this task, you can set the work item link type and target work item.
And other conditions about the work item.
You can set the Control Options as below.
It means, only when the test task has failed, this task will run.
Hops this will help.
So, for anyone else searching, I was able to resolve my issue.
What ended up being the solution was using the Create Test Suite from Requirement option, within a Test Plan. This is a very useful method for our use, as once the Test Suite is setup, and Test Cases which are created with a Tested By/Test Relationship (User case should show Tested By in the Related Work section, the test case will show a Tests entry to the User story) will automatically be added into the Test Suite. Then, when testing, when you create a new Bug from within a Test Execution, will automatically be created with the User Story as a Parent to the Bug.
I am not by any means a sophisticated github user. I have learned the minimum handful of commands needed to add, commit, and push my project code to the public github.com repository. So far it's been working fairly well... until today when I tried to create a new release (my third).
For some reason, when I try to publish my new release, I get the message
Tag could not be created. Pre-receive hooks failed.
I have never seen this message before.
I have tried various different tag names; I have tried logging out and back in again; I have tried pre-tagging on my local disk copy of the repo; I have pushed and pulled (both ends are up to date). This about exhausts my repertoire of things to try :-(
As a relative n00b I find this message incredibly opaque (sigh). I have tried googling for it, but quickly got in over my head -- most of the hits I found were discussions about people setting up their own networked repos and installing or tweaking their own custom "pre-receive hooks", whereas I am just a dumb user of github.com apparently struggling with whatever "pre-receive hooks" they have installed (?). If anyone can at least point me in the right direction I'd be most grateful.
Make sure you select the tag version in the dropdown. The GitHub form will let you submit when this field is blank, but it will always display the mentioned error message. (You do not need a 'v' prefix.).
The latest Github form makes this more cryptic by having a dropdown titled 'Tag:Choose or Create" that hides the fact that this field is both required but not set.
Latest Github Form
Older Github Form
In a GitHub context, I have seen that error message in this issue
It could be a tag naming convention issue.
The GitHub release documentation recommends (enforces?) a tag following the semantic versioning naming scheme: vX.Y.Z.
As shown here, try vx.y.z.
I have set up Jenkins to use the GitHub pull request builder. It's working great! Except one little thing. My test suite creates HTML Reports (which I have beautifully posted using the HTML result poster plugin) but I can't seem to change the status message that gets posted to GitHub. My commits all get marked like:
The status of the commit gets updated properly, but the message part always says "Build finished. No test results found."
I can't seem to figure out how to change this message based on the status of the test suite. So, basically the only feedback I'm getting is the exit status of my shell script. This script does all of the building, testing, and handling of results, etc. This is reasonably acceptable in the event of a pass, but in the event of a failure, this message could be much more helpful! Even just knowing whether it was a build failure vs. a test suite failure would be nice, so then I can adequately verbally abuse the person who made the pull request :).
Everything else is working so good, that I can't figure out what seems like a trivial change is driving me crazy! Any ideas?
FWIW, the logic was added here: https://github.com/janinko/ghprb/commit/ffbc581d2712d6b99b9c6d0b081d7895a5ee8039
I believe you just need to generate JUnit formatted test output, and you may or may not need to ad a post-build step to publish the JUnit XML output.
I have a basic scheduled workflow that creates issues, but can't get the flow to trigger as it should on the projects to which it is attached:
I have 3 projects: A, B and C
I have a scheduled workflow that creates a single issue (summary and description only) in each of A, B and C.
When the workflow is attached to project B, it triggers and all 3 issues are created.
When the workflow is attached to A and/or C, the workflow does not trigger.
Many of the project fields overlap, but given that I'm only setting the summary and description, i don't see that being a problem?
I can't find where workflow execution gets logged, so don't know if there are problems (but the flow does execute on project B)...?
Any help appreciated!
Be aware that stateless and state machine rules are executed on behalf of a user who actually made changes that triggered a workflow. Scheduled rules, in turn, run on behalf of their author. Thus, make sure the author has respective permissions in all of the projects the rule is attached to.
Although not an answer to the problem, this problem was resolved by upgrading from YT5 to YT6.
Part of the upgrade involved going through this problem: http://forum.jetbrains.com/thread/YouTrack-1810 (resolved by backing up, uninstalling YT5, removing all YT folders, then installing YT and restoring backup)
That leads me to wonder if the problem wasn't related to a bad/locked/corrupted file somewhere in the YT directory?
Nevertheless, post upgrade, I attached the scheduled workflows as they were and they fired without hindrance.