Plated or still on the pass: beady-eye 0.34 shows which beads are out for delivery

A ticket whose food is already plated should not still be on the cook’s list. In beady-eye 0.34.0, a ready bead whose pull request has merged leaves ready in a bead’s tree and is listed under delivered, to close rather than start. A bead held by an open pull request is listed under in_delivery. Each names the pull_requests it goes through.

brew upgrade codeforbreakfast/tap/bdi
# or
cargo install beady-eye

spoon $ bdi --beads spoon-9 | jq -r '.ready[] | "\(.id)  \(.title)"'
spoon-3  Chalk Saturday's specials on the board
spoon $ bdi --beads spoon-9 | jq -r '.in_delivery[] | "\(.id)  #\(.pull_requests[].number)  \(.title)"'
spoon-4  #42  Ring up a full English as one item
spoon $ bdi --beads spoon-9 | jq -r '.delivered[] | "\(.id)  #\(.pull_requests[].number)  \(.title)"'
spoon-5  #40  Print the table number on every ticket
spoon $

Three piles on the pass

bdi --beads <bead> writes a bead’s dependency tree. Its ready list now holds only work to start. A bead waiting on a pull request that is still open sits under in_delivery, and a ready bead whose pull request has merged sits under delivered:

bdi --beads spoon-9 | jq '.delivered[].id'

That move happens with or without any new config. If a script of yours reads .ready[] and should still see such a bead, have it read .delivered[] too.

Say how your kitchen marks it

A new [delivery] section in the config names two things. outside_key is the metadata key that marks a gate as another effort’s pull request. outcome_label is the label that marks a molecule’s outcome step. Neither has a default. Without the section, every pull request’s gate delivers a bead and no step is an outcome step.

Service!