Jira Integration
Hand a Jira work item to a Rock8Cloud agent and get a pull request back
Assign a Jira work item to Rock8Cloud and an agent reads the ticket, implements it on a branch named after the issue key, and opens a pull request for review. The result comes back as a comment on the work item when the run finishes, whether it worked or failed. Anything before that - a question, or a reason nothing could start - stays in the Agents panel, so the ticket does not fill up with the conversation.
The Jira app is not on the Atlassian Marketplace yet. Assigning work items to an agent relies on Atlassian's Rovo agent connector, which is still in Atlassian's Preview program, so the app installs from a direct link instead of a listing. Everything after the install works the same either way.
Connect a Jira site
The whole setup starts in Rock8Cloud, and no credentials are shared either way.
- In Rock8Cloud, open Settings → Integrations → Jira and click Connect site
- Enter the site's address, the one you use to open Jira -
acme.atlassian.net. Rock8Cloud checks that a Jira site answers there before it starts anything, so a misspelled address is refused straight away rather than waiting for an install that never comes - Click Connect. A small window opens on that site. If the app is not installed there yet it opens the Atlassian install page - pick the site and confirm. If it is already installed the window goes straight to the next step.
- The window shows the Rock8Cloud page inside Jira, where your request is waiting
- Click Accept. The window closes and the site appears in Rock8Cloud.
Steps 3 and 5 need a Jira site admin, because only an admin can add an app to a site or accept a connection on its behalf. Step 1 needs a Rock8Cloud owner. If those are two people, leave the request running and send it to them: once the app is on the site, the waiting row offers Copy link for your Jira admin, which is the Rock8Cloud page in Jira with your request on it, naming your organization and your email. It waits there for 24 hours. Without the link they can reach the same page through Apps → Manage apps → Rock8Cloud in Jira.
The app asks for permission to read and write work items. Nothing is read until someone assigns a work item to Rock8Cloud, and no repository work happens outside the projects you map in the next step.
If something interrupts it
The pairing lives on the Rock8Cloud side, not in the window, so closing the window, having it blocked, or coming back tomorrow all leave it exactly where it was. The waiting site stays listed, and Cancel drops it. The row's own button reopens the window wherever the pairing has got to: Open install page while the app is still missing from the site, Continue once it is there and a Jira admin has to accept. Neither is needed if the window is still open - the row moves on by itself, and so does the window.
A pairing that ends without connecting - declined, or nobody accepted inside the day - stays on the page saying so, with Start again to send it afresh to the same site. Dismiss it with the × when you are done with it.
Each connected site carries Open in Jira, which goes to the Rock8Cloud page on that site. That is where a Jira admin sees every organization connected to it, and where they disconnect one.
One Jira site can serve several organizations, so connecting does not take the site away from anyone already using it. Connect once per organization - each one sends its own request. An organization can also work with several Jira sites, so connecting a second site does not disturb the first. Connecting the same site to the same organization twice is the only thing refused.
Connecting a site is an owner's decision, and so is mapping projects and disconnecting. Members see the Jira page and what is connected, and cannot change it.
Running one Jira site for several clients works the way you would expect: a Jira project per client, a Rock8Cloud organization per client, and as many projects as you like for your own work. It works in the other direction too - an organization moving between two Jira sites, or working its own site alongside a client's, keeps both connected. Each Jira project belongs to the organization that mapped it, and that is the organization its work items are implemented and billed under.
Map Jira projects to services
Nothing runs until a Jira project is mapped to a service. The mapping is what tells the agent which repository to work in.
- In Rock8Cloud, open Settings → Integrations → Jira. Owners only - other members see the section only if you send them the link, and read it without being able to change it.
- Each connected Jira site has its own card. In the card for the site you want, fill in:
- Jira project - picked from the projects Rock8Cloud can see on that site
- Service - only repository-backed services appear here
- Base branch - leave blank to use the service's own default branch
- Click Add mapping
Each mapping has an Enabled switch. Flip it to Paused to stop runs for that project without deleting the mapping. Work items in a project with no mapping are ignored.
A mapping whose service has lost its repository is marked No repository. It stays in the list, and work items routed to it are refused until the service has a repository again.
A Jira project can be mapped by one organization only. If a project key comes back as already mapped and it is not in your list, another organization on the same Jira site is using it - ask your Jira site admin, who can see every organization connected to the site on the Rock8Cloud page in Jira.
Several repositories in one project
A Jira project can be mapped to as many repositories as you like: add a mapping per repository, all with the same Jira project. The settings page then groups them under that project key.
This changes how every work item in that project is handled. One work item is implemented in exactly one repository, so once a project has more than one, Rock8Cloud needs to be told which.
Rock8Cloud adds a Repository field to your Jira site for that. It sits in Details, beside Labels, and offers the repositories mapped to that work item's project. It holds one of them, and reads Add repository until it does.
On a company-managed project a Jira admin has to add Repository to the project's screens before anyone can set it. In Jira: Project settings → Screens. Until then the field does not appear and Rock8Cloud reads it as empty. Team-managed projects pick the field up on their own.
There are two ways to say which repository, and neither needs the other:
- Answer the question. Assign the work item to Rock8Cloud. It asks which repository, listing them, and you reply with the name. It starts there and saves your answer to the Repository field, so nobody has to answer twice for that work item.
- Set the field first. Open the work item, set Repository, then assign it. Nothing is asked.
A reply does not have to be the whole name - enough of it to be unique is fine, so strapi picks solar-prism-dde-strapi. If what you type fits more than one, Rock8Cloud asks again between just those, rather than guessing: a run in the wrong repository costs a branch and a pull request.
Answer within a day. After that Rock8Cloud has forgotten which work item the question was about, and a bare name reads as a new conversation - assign the work item again, or set the field.
You can say more than the name in the same reply. "solar-prism-dde-web, and update the README too" starts in that repository and passes the rest to the agent as an instruction.
With one repository mapped there is nothing to decide, so the field shows that repository greyed out and Rock8Cloud ignores whatever it holds.
Paused repositories, and ones whose service has lost its repository, are shown in the field marked (paused) or (no repository), cannot be chosen, and are not offered as an answer either.
Because the field holds names, renaming a repository in Rock8Cloud leaves the old name behind on work items that named it. Assigning one of those is refused with the current names, rather than run somewhere nobody chose - and you can answer that question with a reply too.
A ticket that needs two repositories
Repository holds one repository, so a work item cannot ask for two. Split it into one work item per repository instead.
That is deliberate, not a limitation we plan to lift. An agent only ever sees the repository it works in, and two agents started from one ticket cannot see each other's work. Asked to build an API on one side and the page that calls it on the other, each would invent the contract between them separately, and the two pull requests would not fit together.
Splitting the ticket is how that contract gets written down once, by someone who can see both sides. Give each work item the repository it belongs to and say what that side has to build - including the shape of the interface between them - then assign them separately.
A follow-up reply on a work item continues the repository it already ran in, whatever the reply mentions. You do not have to set the field again. To move the work somewhere else, set the Repository field to the repository you want.
Start a run
There is one way to start a run, and it happens entirely in Jira:
- Assign the work item to Rock8Cloud in the Agents panel, or
- Mention Rock8Cloud in the panel and ask it to implement the ticket
The agent then reads the summary, description, labels, components and comments, works on a branch named after the issue key, and opens a pull request. The Agents panel shows the task moving from queued to working, with elapsed time while the turn runs.
If two Jira sites are mapped to the same repository, only the site whose mapping was added first uses the bare issue key - work items from the others get their site's name in front of the branch (acme-OPS-12), so two tickets that happen to share a number never land on one branch. Mapping a second site therefore never moves a branch that is already in flight.
Runs are one at a time per work item. Assigning the same ticket again while a run is in flight shows you the run already going, rather than starting a second one.
What lands on the work item
When the run finishes, Rock8Cloud comments on the ticket with:
- what it changed, in its own words
- a link to the pull request, plus how many files changed and on which branch
The agent session appears in the work item's links section as soon as the run is queued, so you can follow it in Rock8Cloud while it works. The pull request joins it when the run finishes, and the session link then points at the full transcript. Assigning the same ticket again continues on the same branch and updates the same pull request instead of opening a rival one.
When the ticket is not ready
If the ticket does not describe an actionable change, or answering it would mean guessing, the agent changes nothing and asks instead. The Needs more detail answer, with the specific questions that would make the ticket actionable, appears in the Agents panel. It is not commented on the work item: it is a question rather than a result, and the panel is where you answer it.
Two ways forward:
- Reply to Rock8Cloud in the Agents panel with the missing detail. The reply continues the same session and branch.
- Update the ticket and assign it to Rock8Cloud again.
Pause or disconnect
| What you want | Where |
|---|---|
| Stop runs for one project | Flip its mapping to Paused in Settings → Integrations → Jira |
| Disconnect one of your sites | Click Disconnect next to it in Settings → Integrations → Jira |
| Disconnect one organization from the site | Click Disconnect next to it on the Rock8Cloud page in Jira |
| Disconnect every organization on the site | Click Disconnect all on the Rock8Cloud page in Jira |
| Remove the app entirely | Uninstall Rock8Cloud from Apps → Manage apps in Jira |
Disconnecting an organization deletes its project mappings and stops its work items reaching Rock8Cloud. Other organizations on the site keep working. The app stays installed, so the organization can be paired again later from the same button. Either side can disconnect, which means a Jira site admin can release an organization without waiting for its admin.
Uninstalling the app disconnects every organization on the site. Reinstalling it does not bring them back - each one pairs again.
Troubleshooting
A connected site cannot be read. Opening its projects says Rock8Cloud cannot read that Jira site right now. That almost always means the app was uninstalled there, and Jira does not reliably tell us when it happens, so the site keeps its place in the list until you decide. Open the Rock8Cloud page in Jira to put the app back, or click Disconnect to drop the site and its project mappings.
The connection is still waiting. A request lasts 24 hours and needs a Jira site admin to accept it on the Rock8Cloud page in Jira. If it still says "waiting for install" after the app is installed, press Get started on the Jira install screen, or Open in Jira on the row. Opening the Rock8Cloud page in Jira moves the request on at once. Otherwise the row updates itself within a few minutes. Longer than that means the app is not on that site yet, or the address belongs to a different site, so cancel and start again. After 10 attempts your whole organization waits up to 15 minutes before another is accepted.
It says this Jira site is already connected. The organization you are working in already has that site, so there is nothing to ask for and its projects are mappable under Settings → Integrations → Jira right now. Switch organizations in the header to connect the same site to a different one.
Rock8Cloud says the project is already mapped, but it is not in my list. Another organization on the same Jira site mapped that project. A project belongs to one organization. Your Jira site admin can see which organizations are connected on the Rock8Cloud page in Jira.
Nothing happens when I assign the work item. The project is not mapped, its mapping is Paused, or the mapped service has no repository attached. The Agents panel says which, and names the page that fixes it. Once it is fixed, reply "try again" in the panel and Rock8Cloud picks the work item back up, as long as you do it within a day. After that, assign the work item again. The Rock8Cloud page in Jira also lists the projects that are actually mapped.
Rock8Cloud asks which repository every time. The project is mapped to more than one and the work item's Repository field is empty. It is per work item, so a new ticket starts empty. Answering by reply saves it to the field, unless the field is missing from the project's screens - then the answer starts the run but cannot be stored, so the next work item asks again.
There is no Repository field on my work items. The project is company-managed and a Jira admin has not added the field to its screens yet: Project settings → Screens.
I chose a repository and Rock8Cloud still asks. The one you chose has since been renamed, unmapped, paused, or its service lost its repository, so it is no longer on offer. The answer in the panel lists what is. Rock8Cloud will not quietly run somewhere you did not choose.
Rock8Cloud says two repositories share that name. The project is mapped to two repositories with the same name, in different Rock8Cloud projects, so the name cannot say which. Rename one, or map only one, under Settings → Integrations → Jira.
The agent says this Jira site is not connected. The app is installed but your organization never paired with it, or it has been disconnected. Pair again from Settings → Marketplace Apps → Rock8Cloud in Jira.
The agent says its Jira access has expired. Its access token has lapsed. Open Settings → Marketplace Apps → Rock8Cloud in Jira once, which restores it, then assign the work item again.