How to reduce login actions for multiple requests (JCLI)

This page is Deprecated. With version 4.5 and higher, most actions are REST API based and this support is not applicable for that. Furthermore, Jira 7.0 and above only REST APIs are used.


For SOAP based CLI actions (many Jira Command Line Interface (CLI) actions and almost all Confluence Command Line Interface actions), each request requires a login. The CLI does this automatically for you and also does an explicit logout. If you are doing a very large number of requests, there are ways to reduce the number of login actions. This will reduce the load on your server and may improve the performance of your actions. Note, this only applies to CLI requests based on SOAP interfaces, not REST interfaces.

Using a login token

For repeated actions, the login can be done once and re-used. Write the login token to a file by redirecting stdout to a file and then re-used by using the -l (--loginFromStandardInput) flag to read it back from stdin. The token is valid for a limited time (Atlassian default is usually 30 minutes) and is invalid after the logout action is taken.

Only works for SOAP based actions

Many Jira actions and a few Confluence actions now use REST based interfaces which require user and password on each request. While using the token may still provide some benefit, a valid password must still be provided on each request to enable the REST based interface to work. Errors or incorrect results may be shown if the password is missing or invalid.

Jira plans to discontinue SOAP based actions in the future meaning that a valid password will be required on each action since they will be based on a REST interface. See this notice.

Instructions

  1. Put the login token in a file called login
  2. Run an action
  3. Do an explicit logout - not necessary, but a good practice

    jira --action login > login
    jira --action getProjectList -l < login
    jira --action logout -l < login
    

Alternative

  1. Get the 10 character login value using the login action
  2. Put the 10 character login value on the --loginparameter on subsequent requests

    jira --action login
    e4gSG5yX0a
    jira --action getProjectList --login e4gSG5yX0a
    

Using the run action

New for 2.0.0 and later, multiple actions can be run with one request. In these cases, the token is preserved automatically.

Instructions

  1. Create a file (actions.txt) where each line is a partial action request - only action specific options should be specified
  2. On the command line, use the run action. You may want to use the --continue option to continue running actions even if a previous one failed

    jira --action run --file actions.txt
    

Example actions.txt contents

# This is a comment
--action getProjectList

# Another comment
--action getServerInfo

Using the runFromSql action

New for 2.0.0 and later. Similar to the run action, accept the actions come from a suitably constructed SQL query.

Instructions

  1. Create a file (sql.txt) with your SQL statement that produces partial action requests - only action specific options should be generated from the sql
  2. On the command line, use the runFromSql action. You may want to use the --continue option to continue running actions even if a previous one failed
  3. Specify database access parameters

     
    jira --action runFromSql --file sql.txt --host localHost --driver postgresql --database jiraDatabase
    

Example sql.txt contents

select '--action getIssue --issue ' || pkey from jiraissue

Direct SQL

Instead of using a file for the SQL, you can use the --sql option directly on the command line. This works fine for simple SQL statements, but more complex SQL statements using special characters may get messed up by the command line interpreter especially on Windows

Problem determination

  • Test your SQL out separately to ensure it creates valid partial action requests
  • Verify that the database connection works from the client you intend to use to run the Jira CLI request

Are you sure?

  • Run against a test instance to ensure your actions do what is intended
  • Consider using the --simulate option to look at what would be done and verify it is what you want to do