Auto-assign Build Failure Investigator

Create an issue when a build fails, assign an investigator, and close the issue when a later build succeeds.

Check issue fields

In Administration > Issue Settings > Fields, verify these default fields exist:

• Type, with the choice Build Failed.
• Assignees, a User field that allows multiple values and an empty value.
• Build, a Build field shown when Type is Build Failed.

The built-in investigator script finds the committer of the build's current commit by verified email address. It returns that user's login name, or no investigator when no verified user matches. It does not select every developer who committed since the last successful build.

Configure automatic recovery

In Administration > Issue Settings > State Transitions, add a Build is successful rule. Do not assume this rule is already present in your installation.

Set From States to Open, To State to Closed, Applicable Jobs to failure-investigation, and Applicable Branches to main. For Applicable Issues, use:

"Project" is "tutorial-issues" and "Type" is "Build Failed" and ("Build" is current or "Build" is previous)

Replace the project, job, branch, and state names with yours. Keep this rule above other matching rules, since the first matching rule applies.

Create the failure issue

Create a Docker job using the following build spec. In the visual editor, the action is under Post-build Actions > Create issue. For Assignees and Build, choose Evaluate script to get value and select the built-in scripts shown below.

version: 53
jobs:
- name: failure-investigation
  steps:
  - !CommandStep
    name: Test application
    runInContainer: true
    image: alpine:3.20
    interpreter: !PosixInterpreter
      shell: sh
      commands: exit 1
    runAs: '0:0'
    useTTY: false
    condition: SUCCESSFUL
  postBuildActions:
  - !CreateIssueAction
    condition: failed
    issueTitle: 'Investigate failure of build #@build_number@'
    issueDescription: 'Investigate the failed tutorial build.'
    issueConfidential: false
    issueFields:
    - name: Type
      valueProvider: !SpecifiedValue
        value: [Build Failed]
    - name: Priority
      valueProvider: !SpecifiedValue
        value: [Normal]
    - name: Assignees
      valueProvider: !ScriptingValue
        scriptName: builtin:determine-build-failure-investigator
    - name: Build
      valueProvider: !ScriptingValue
        scriptName: builtin:get-build-number
  retryCondition: never
  maxRetries: 3
  retryDelay: 30
  timeout: 3600

This example includes the standard issue fields. If your installation defines additional fields, configure those in the action too; build-spec validation reports missing fields. Use appropriate values for required custom fields.

Verify failure and recovery

1. Run failure-investigation. Its deliberate exit 1 fails the build and creates an Open issue with Type Build Failed, a reference to the failed build, and the matching committer as investigator.
2. Change the command to exit 0, commit to main, and run the same job again.
3. Open the issue. It should be Closed, with an activity explaining that the subsequent build succeeded.

For repeated failures, choose a post-action condition appropriate to your workflow: failed creates an issue on every failed run, so repeated failures can create multiple issues.