Skip to main content
If your organization has connected Linear or Jira to Peeps, your agent can see and manage the links between your tracker’s issues and your tests.
An admin connects Linear or Jira in Peeps settings, under Issue tracking, on the website. An organization connects one tracker at a time. Your agent can’t connect it for you.

​
See linked issues

Is there an issue for the checkout failure?
Your agent lists the issues linked to a test case, a run or a batch run, with each issue’s identifier, title, state and link. For a test case, it also lists the issues linked to that test case’s runs. It can also answer for a group of test cases at once, such as the failing tests of a release: whether an open issue tracks any of them, only closed ones, or none.

​
Check whether a failure is already tracked

After Peeps analyzes a failure, it checks whether an existing issue may already describe it, so you can link that issue instead of filing a duplicate. In the web app these appear as Possibly already tracked on the run’s analysis.
Is this failure possibly already tracked?
Your agent sees the same suggestions. Each one comes with:
  • the issue’s identifier, title, status and link, and for a closed issue why it closed: done (a possible regression), closed without a fix, or archived
  • how confident Peeps is, and why: the same error, the same page, the same feature, the same test, or an issue closed recently
  • whether it is already linked
A matching issue that was closed as done may be a regression: you can reopen it, as described below. For a run in a batch, Peeps matches once the batch finishes, so your agent may report that matching is still waiting. Peeps only suggests. Nothing is linked until you say so. Link a suggestion. Tell your agent which one. It links it as described below.
Link the first suggestion to this run.
Reopen a closed issue. When a suggested issue was closed as done, the failure may be back. In the web app the suggestion shows Reopen, and your agent can do the same:
SHOP-187 is back. Reopen it and link this run.
Your agent asks you first, naming the issue, because reopening changes the issue in your tracker. Peeps then reads the issue as it is now:
  • If someone already reopened it, Peeps just links it.
  • If it is now archived, or closed without a fix (canceled, won’t do, duplicate), Peeps doesn’t reopen it and offers to link it instead.
  • Otherwise Peeps moves it back to an open status: the team’s first not-started status in Linear, or in Jira a transition to To do (or else In progress) that needs no extra details. Then it links the run, as a link always does.
If your Jira workflow needs details to reopen the issue, or your tracker refuses, Peeps says why and offers Open in Jira and Link instead. If Peeps can’t confirm whether the reopen went through, it doesn’t try again: check the issue in your tracker. If the issue reopened but the link didn’t, link it again. Peeps never reopens an issue that is already linked to the run, or one you said is “Not this one”. Say “Not this one”. If a suggested issue doesn’t describe this failure, tell your agent. Peeps stops suggesting that issue for this failure, on every run of it. Nothing changes in your tracker. Your agent does this only when you say so, never on its own judgement. To remove an issue that is already linked, unlink it instead.
ENG-98 isn’t this failure.

​
Where suggestions come from

By default, Peeps suggests only issues already linked in Peeps: to the test case, its earlier runs, the tests it depends on, or other runs that failed the same way. It considers them while they are open, or for a year after they close, so a regression months later is still caught. Those linked issues also inform Peeps’s failure analysis. An admin can also let Peeps search the tracker for issues not yet linked, open or closed in the last 90 days, and choose which teams or spaces it searches. This is off by default, and it is set in Peeps settings, under Issue tracking, not by your agent. When it is on, Peeps reads the start of up to five candidate issues’ descriptions, and an AI model judges which ones match. Peeps never stores those descriptions.
Link ENG-123 to this failing run.
Name the issue by its identifier or its link from the tracker. Your agent asks you first, because linking also adds a link back to Peeps on the issue in your tracker. Linking an issue that is already linked there changes nothing. You can link one issue to many targets in one go: up to 100 test cases of one project, or the runs of a batch that the issue is about.
Link ENG-123 to all the guest-checkout tests.
Unlink ENG-123 from the checkout test.
Your agent asks you first. Unlinking removes the link back to Peeps from the issue in your tracker. The issue itself is never changed or deleted. Peeps also stops suggesting that issue for the same failure.

​
Create an issue

File a bug for this failure in the Payments team.
Your agent finds where the issue can go, such as a Linear team or a Jira space, and the fields its form needs. If there is more than one place, it asks you which. Before it creates anything, it shows you the destination, the title, the description and every field value, and waits for your approval. Peeps creates the issue, links it to the test case, run or batch run, and ends its description by naming you as the Peeps user who opened it. For a batch run, the issue is linked to the runs of the test cases it is about. Peeps points out possible duplicates first. If Peeps already suggests issues that may describe this failure, it doesn’t create a new one straight away. Your agent shows you those issues and offers to link one instead. It creates a new issue only after you choose to. If Peeps can’t confirm whether your tracker created the issue, your agent doesn’t try again, because that could file it twice. It gives you a link to the Peeps page, where you check your tracker and finish it.

​
Permissions

See permissions and approvals.