In this page

Configuring app logging

When investigating a run-time problem, you may need to increase the logging level for the app. Doing so, the app writes more run-time details to the Jira log which helps us understand what's going on.

To increase the logging level from the web interface without stopping Jira:

  1. Login to Jira as administrator.
  2. Go to Jira AdministrationSystemLogging and Profiling.
  3. Click Configure logging level for another package under Default Loggers.
  4. Enter "com.midori" to Package Name and choose "DEBUG" in Logging Level. (You can alternatively choose "TRACE", the most detailed logging level, but it may produce a very high number of log entries.)
  5. Click Add.
  6. Check if this new package was correctly added to the Default Loggers list.

Now execute the app function that you think fails, and check your Jira log to see the details.

If you can't understand the log lines, report what you have found to our support. We are there to help you.

Typical problems and their solutions

This section gives you practical hints to find the root cause when facing non-trivial problems.

My DevOps automation rule is not executed.

It can be caused by many different reasons. Follow these steps to investigate the root cause:

  1. Go to the Audit Log of the automation rule.
  2. Check if there is a log entry created for your last rule execution?
    • If there isn't, the rule was not executed. In this case:
      1. Wait for some minutes, then check the log again because there may be little delays in the rule execution. Check if the log entry is still missing?
      2. Check if the pre-conditions written in the configuration guide are met?
      3. Check if you precisely followed each step of the configuration guide?
    • If there is, the rule was executed. In this case:
      1. View the log entry details for the execution status:
        • Not successful?
          1. If the rule requires issues, check if at least one issue key was mentioned in the commit message?
          2. View the error message in the log entry for the root cause of the problem, and fix the root cause.
        • Successful?
          1. It means that the trigger worked correctly (i.e. the Better DevOps Automation app successfully completed its part), but the actions, conditions or other components if the rule didn't (i.e. the Automation for Jira app failed with its part). Please contact the Atlassian support with the problem.

I see "Failed to parse command parameter ..." errors in the audit log.

It means that the command parameter pattern could not be matched to the parameters that the developer entered to the commit message. For example, he entered the command "@status", but without a status name. The audit log shows both the parameter pattern and the part of the commit message that app tried to parse, therefore you can confirm the precise cause.

You can prevent these types of problems by enforcing the correct command parameters with a commit policy.

For additional debugging, you can use the Log action and write the command parameters to the audit log. Reminder: the command parameter called "foo" is available as the smart value named {{}})

I see "ClassNotFoundException: com.codebarrel.automation...EventTriggerRuleComponent not found" errors in the Jira log.

Due to a internal classloading quirk in the Jira app container, the Better DevOps Automation for Jira app must be installed after the Automation for Jira app. Otherwise this exception is thrown.

Fix: just uninstall and re-install the Better DevOps Automation for Jira app. It guarantees the correct order.

(Although the Better DevOps Automation app can't resolve the problem by itself, at least it detects the problem and displays the fixing instructions in the Genius Commands screen and at the triggers' configuration form. That way, the problem doesn't remain hidden.)

I see "ComponentInputs.getIssues() crashed!" errors in the audit log.

This is a known bug in the Automation for Jira app. We reported this for Atlassian, and it is tracked as JRASERVER-72132. We strongly encourage you to vote for the bug, to increase its importance for the Automation for Jira developer team.

As far as we know, it happens only if all the following relatively rare conditions are true:

  1. Your rule uses a DevOps automation trigger.
  2. Your rule uses a DevOps automation action.
  3. Your rule uses a "Branch rule / related issues" component in front of the DevOps action somewhere, and it receives more than one issue as input.

As workaround, try to implement your automation rule in a way that at least one of these are not applicable to your implementation.


Ask us any time.