Skip to content

Find Tickets

As part of Quick Start there's a call documented for finding all the tickets ready to be transitioned.

tickets_to_move = find_tickets_to_move

This will also flag tickets that appear to be in the incorrect state.

Example

State = "Awaiting QA Release" + All PRs declined.

Custom Flag Messages

These flag messages can be customised as follows.

require "apadmi_grout" # Additional import needed
...

tickets_to_move = find_tickets_to_move(
  custom_flag_messages: Apadmi::Grout::FlagMessages.new(
    "REASON FOR FLAG: Check this ticket - it has no PRs connected to it. CI still moved it",
    "REASON FOR FLAG: Check this ticket - it has no MERGED PRs and at least one OPEN PR",
    "REASON FOR FLAG: Check this ticket - it has only DECLINED PRs",
    "REASON FOR FLAG: Check this ticket - it has no MERGED PRs"
  )
)

(See Yard doc for detail)

Kanban & Backlog Tickets

By default Grout won't move tickets that don't have a Sprint assigned.

This can be a problem for projects working Kanban.

Override this behaviour as follows.

require "apadmi_grout" # Additional import needed
...
  tickets_to_move = find_tickets_to_move(
    options: Apadmi::Grout::JiraFindTicketsOptions.new(
      include_no_sprint_tickets: true
    )
  )

Identifying tickets to move

JIRA

This is actually trickier than it might seem. The following is a list of conditions a ticket must fulfill in order to be moved.

  1. Have an assigned Sprint (unless this is suppressed by the option above)
  2. Have the supplied Component assigned (or a blank component) *
  3. Be in the supplied status (unless status is blank, in which case any status considered, recommend NOT doing this) *
  4. At least one of the following is true
    • Ticket has NO associated PRs (ticket will be flagged but still moved)
    • Ticket has at least one merged PR AND the ticket id appears in the changelog**.

* In the above example these parameters are pulled from Environment variables.

** This should for the most part stop builds from moving tickets who's PRs were merged after the build was triggered.

ADO

For ADO we have none of the pull request functionality. The checks are much simpler:

  • If a ticket is in the changelog, it's moved
  • If a ticket is not in the changelog at all, it's flagged and moved
  • If a ticket is in the changelog but not in the history from the current commit, it's not moved. (For example PRs merged after the build was triggered.)

Caveats and Edge cases

Again, this is hard to get right, so here's a few cases where things can go wrong.

  1. A ticket is merged, put through QA and sent back, another PR being needed which is open. If another build is triggered in the meantime this ticket would be moved over incorrectly.
  2. Ticket has no PRs but is considered ready to move, but is moved over by the wrong build (e.g a release build instead of a dev build), this would leave it with the incorrect fix versions.

If you have any suggestions on improving / mitigating these edge cases please visit the Contributing section.

Yard Reference

Back to top