One Run notification for a Pickup run that took an issue #285

Parent

#212

What to build

A Pickup run asked for a Run notification, by email or by email.always in the User config without no-email, sends exactly one when it took a Ready issue: the notification the Spec run or Run it dispatched would have sent by hand, with that run's subject, outcome and body. The dispatched run sends none of its own, whatever the User config says, as with an Architect run.

A skipped Pickup run sends no notification, even when one was asked for: a pass every half hour would otherwise send dozens a day. This differs from a skipped Architect run, which does send one.

The notification's checks, an address and a Resend API key, are made before any other work on every pass, so a broken setup stops the pass with exit 1 and shows in the cron log, even on a pass that would have been skipped.

Acceptance criteria

• A pass that took an issue and was asked for a notification sends exactly one, after the outcome is final, for each ending: ready for review, merged, failed and interrupted.
• Its subject and body are those of a Run's notification for that issue, or of a Spec run's with a line per Ticket.
• email <address> wins over email.to, and no-email sends none when email.always is set.
• The dispatched run sends no notification of its own with email.always set.
• A pass skipped for the lock, for having no Ready issue or for the Claim limit sends none.
• A pass asked for a notification with no address or no key exits 1 naming what is missing, before any label changes or session.
• A notification that can't be sent is a warning: line and changes neither the exit code nor stdout.
• The README's Run notifications section covers the Pickup run.
• End-to-end cases cover the above with the Resend stand-in, as the Architect run's notification tests do.

Blocked by

• thirdshift pickup: take the lowest-numbered Ready issue and run it #282