blob: 3fdb7b15cad60c1cf8b4a484d5febcf79317179e [file] [log] [blame]
= Jira Component
:doctitle: Jira
:shortname: jira
:artifactid: camel-jira
:description: Interact with JIRA issue tracker.
:since: 3.0
:supportlevel: Stable
:tabs-sync-option:
:component-header: Both producer and consumer are supported
//Manually maintained attributes
:camel-spring-boot-name: jira
*Since Camel {since}*
*{component-header}*
The JIRA component interacts with the JIRA API by encapsulating
Atlassian's https://bitbucket.org/atlassian/jira-rest-java-client/src/master/[REST
Java Client for JIRA]. It currently provides polling for new issues and
new comments. It is also able to create new issues, add comments, change issues, add/remove watchers, add attachment
and transition the state of an issue.
Rather than webhooks, this endpoint relies on simple polling. Reasons
include:
* Concern for reliability/stability
* The types of payloads we're polling aren't typically large (plus, paging is available in the API)
* The need to support apps running somewhere not publicly accessible where a webhook would fail
Note that the JIRA API is fairly expansive. Therefore, this component could be easily expanded to provide additional
interactions.
Maven users will need to add the following dependency to their pom.xml
for this component:
[source,xml]
---------------------------------------
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-jira</artifactId>
<version>${camel-version}</version>
</dependency>
---------------------------------------
[NOTE]
====
Atlassian does not release their JIRA Java client's to Maven Central.
Therefore, when using `camel-jira` then the `pom.xml` has included Maven repository
to the following URL: `https://packages.atlassian.com/maven-external`.
Just keep this in mind as Maven will then use this repository to download the JIRA client (and potentially other JARs).
Which allows Atlassian to track these downloads by their servers.
====
== URI format
-------------------------
jira://type[?options]
-------------------------
The Jira type accepts the following operations:
For consumers:
* newIssues: retrieve only new issues after the route is started
* newComments: retrieve only new comments after the route is started
* watchUpdates: retrieve only updated fields/issues based on provided jql
For producers:
* addIssue: add an issue
* addComment: add a comment on a given issue
* attach: add an attachment on a given issue
* deleteIssue: delete a given issue
* updateIssue: update fields of a given issue
* transitionIssue: transition a status of a given issue
* watchers: add/remove watchers of a given issue
As Jira is fully customizable, you must assure the fields IDs exists for the project and workflow, as they can change between different Jira servers.
// component-configure options: START
// component-configure options: END
// component options: START
include::partial$component-configure-options.adoc[]
include::partial$component-endpoint-options.adoc[]
// component options: END
// endpoint options: START
// endpoint options: END
// component headers: START
include::partial$component-endpoint-headers.adoc[]
// component headers: END
== Client Factory
You can bind the `JiraRestClientFactory` with name *JiraRestClientFactory* in the registry to have it automatically set in the Jira endpoint.
== Authentication
Camel-jira supports the following forms of authentication:
* https://developer.atlassian.com/cloud/jira/platform/jira-rest-api-basic-authentication/[Basic Authentication]
* https://developer.atlassian.com/cloud/jira/platform/jira-rest-api-oauth-authentication/[OAuth 3 legged authentication]
* https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html[Personal Token]*
We recommend to use OAuth or Personal token whenever possible, as it provides the best security for your users and system.
=== Basic authentication requirements:
* An username and a password.
=== OAuth authentication requirements:
Follow the tutorial in https://developer.atlassian.com/cloud/jira/platform/jira-rest-api-oauth-authentication/[Jira OAuth documentation]
to generate the client private key, consumer key, verification code and access token.
* a private key, generated locally on your system.
* A verification code, generated by Jira server.
* The consumer key, set in the Jira server settings.
* An access token, generated by Jira server.
=== Personal access token authentication requirements:
Follow the tutorial to generate the https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html[Personal Token].
* You have to set only the personal token in the `access-token` parameter.
== JQL:
The JQL URI option is used by both consumer endpoints. Theoretically,
items like "project key", etc. could be URI options themselves.
However, by requiring the use of JQL, the consumers become much more
flexible and powerful.
At the bare minimum, the consumers will require the following:
--------------------------------------------------------------
jira://[type]?[required options]&jql=project=[project key]
--------------------------------------------------------------
One important thing to note is that the newIssues consumer will
automatically set the JQL as:
* append `ORDER BY key desc` to your JQL
* prepend `id > latestIssueId` to retrieve issues added after the camel route was started.
This is in order to optimize startup processing, rather than having to index every single
issue in the project.
Another note is that, similarly, the newComments consumer will have to
index every single issue *and* comment in the project. Therefore, for
large projects, it's *vital* to optimize the JQL expression as much as
possible. For example, the JIRA Toolkit Plugin includes a "Number of
comments" custom field -- use '"Number of comments" > 0' in your query.
Also try to minimize based on state (status=Open), increase the polling
delay, etc. Example:
----------------------------------------------------------------------------------------------------------------------------------------------
jira://[type]?[required options]&jql=RAW(project=[project key] AND status in (Open, \"Coding In Progress\") AND \"Number of comments\">0)"
----------------------------------------------------------------------------------------------------------------------------------------------
== Operations
See a list of required headers to set when using the Jira operations. The author field for the producers is automatically set to the authenticated user in the Jira side.
If any required field is not set, then an IllegalArgumentException is throw.
There are operations that requires `id` for fields suchs as: issue type, priority, transition. Check the valid `id` on your jira project as they may differ on a jira installation and project workflow.
== AddIssue
Required:
* `ProjectKey`: The project key, example: CAMEL, HHH, MYP.
* `IssueTypeId` or `IssueTypeName`: The `id` of the issue type or the name of the issue type, you can see the valid list in `\http://jira_server/rest/api/2/issue/createmeta?projectKeys=SAMPLE_KEY`.
* `IssueSummary`: The summary of the issue.
Optional:
* `IssueAssignee`: the assignee user
* `IssueAssigneeId`: the assignee user id
* `IssuePriorityId` or `IssuePriorityName`: The priority of the issue, you can see the valid list in `\http://jira_server/rest/api/2/priority`.
* `IssueComponents`: A list of string with the valid component names.
* `IssueWatchersAdd`: A list of strings with the usernames (or id) to add to the watcher list.
* `IssueDescription`: The description of the issue.
== AddComment
Required:
* `IssueKey`: The issue key identifier.
* body of the exchange is the description.
== Attach
Only one file should attach per invocation.
Required:
* `IssueKey`: The issue key identifier.
* body of the exchange should be of type `File`
== DeleteIssue
Required:
* `IssueKey`: The issue key identifier.
== TransitionIssue
Required:
* `IssueKey`: The issue key identifier.
* `IssueTransitionId`: The issue transition `id`.
* body of the exchange is the description.
== UpdateIssue
* `IssueKey`: The issue key identifier.
* `IssueTypeId` or `IssueTypeName`: The `id` of the issue type or the name of the issue type, you can see the valid list in `\http://jira_server/rest/api/2/issue/createmeta?projectKeys=SAMPLE_KEY`.
* `IssueSummary`: The summary of the issue.
* `IssueAssignee`: the assignee user
* `IssueAssigneeId`: the assignee user id
* `IssuePriorityId` or `IssuePriorityName`: The priority of the issue, you can see the valid list in `\http://jira_server/rest/api/2/priority`.
* `IssueComponents`: A list of string with the valid component names.
* `IssueDescription`: The description of the issue.
== Watcher
* `IssueKey`: The issue key identifier.
* `IssueWatchersAdd`: A list of strings with the usernames (or id) to add to the watcher list.
* `IssueWatchersRemove`: A list of strings with the usernames to remove from the watcher list.
== WatchUpdates (consumer)
* `watchedFields` Comma separated list of fields to watch for changes i.e `Status,Priority,Assignee,Components` etc.
* `sendOnlyUpdatedField` By default only changed field is send as the body.
All messages also contain following headers that add additional info about the change:
* `issueKey`: Key of the updated issue
* `changed`: name of the updated field (i.e Status)
* `watchedIssues`: list of all issue keys that are watched in the time of update
include::spring-boot:partial$starter.adoc[]