(feature) Add trait to ignore pull request edited events

[jmasalma]

Description

Add a new IgnoreEditedPullRequestFilterTrait that suppresses builds triggered by pull request edited webhook events (title or description changes). When this trait is enabled on a GitHub SCM source, editing a PR's title or description will no longer trigger a new build for the same commit.

See JENKINS-65978 / Issue 1361 and JENKINS-67888 / Issue 1385 for further information.

Submitter checklist

• Link to JIRA ticket in description, if appropriate.
• Change is code complete and matches issue description
• Automated tests have been added to exercise the changes
• Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• Run the changes and verify that the change matches the issue description
• Reviewed the code
• Verified that the appropriate tests have been written or valid explanation given

Documentation changes

• Link to jenkins.io PR, or an explanation for why no doc changes are needed
  • No doc changes needed - the trait's display name "Ignore pull request title/description edits" is self-explanatory and consistent with other traits like "Ignore pull requests marked as drafts"

Users/aliases to notify

Relevant to anyone affected by JENKINS-65978 or JENKINS-67888.

Manual test instructions:

1. Configure a multibranch pipeline with a GitHub SCM source
2. Add the behavior "Ignore pull request title/description edits" under Branch Sources -> GitHub -> Behaviors
3. Open a pull request and let a build complete successfully
4. Edit the PR title or description - confirm no new build is triggered
5. Push a new commit to the same PR - confirm a build is triggered normally
6. Without the trait enabled, confirm editing the PR title/description still triggers a build (existing behavior preserved)

[lemeurherve]

FTR:

• [JENKINS-67888] Allow filtering pull request events by type #1385
• [JENKINS-65978] Editing a GitHub PR description should not trigger a new build for the same commit #1361

@jmasalma have you reproduced this issue yourself before opening this pull request?

[jmasalma]

FTR:

• [JENKINS-67888] Allow filtering pull request events by type #1385
• [JENKINS-65978] Editing a GitHub PR description should not trigger a new build for the same commit #1361

@jmasalma have you reproduced this issue yourself before opening this pull request?

@lemeurherve Yes, we reproduced this ourselves. When a PR description is edited (with no new commit), GitHub fires a pull_request event with action: edited, which the plugin handles as an SCMEvent.Type.UPDATED event - triggering a new build against the same commit SHA as the previous run.

We confirmed this by inspecting the BranchEventCause on the triggered build, which shows "Pull request #N event" (the fallthrough description for edited) rather than "Pull request #N updated" (which is only set for synchronize).

The webhook payload from GitHub confirmed the trigger:

  "changes": {
      "body": {
        "from": "WIP..."

We're running Jenkins GitHub Branch Source Plugin 1967.1970.vd86979736546. The behavior is reproducible but not 100% consistent - it only triggers when no build is already queued or running for that PR at the time of the edit, which explains why it doesn't always happen.

[lemeurherve]

Thanks.

Asked because I couldn't reproduce on ci.jenkins.io running Jenkins 2.568.3 (latest LTS) nor on infra.ci.jenkins.io running Jenkins 2.583 (latest Weekly), both using GitHub Branch Source Plugin 1983.vfa_27ed961853.

[jmasalma]

Reproduced with following
GitHub Enterprise Server 3.19.10
Updated PR description: Empty -> some text

Webhook payload shows:

  "changes": {
    "body": {
      "from": ""
    }
  },

Jenkins 2.555.3 with GitHub Branch Source 1967.1970.vd86979736546 installed
New build triggerd with
Pull request #NNNN event

[jmasalma]

@MarkEWaite / @jglick, Sorry to bother you, would you be able to take a look at this? The issue reproduces on GitHub Enterprise Server 3.19.10 with Jenkins 2.555.3. Happy to provide any additional context.

[MarkEWaite]

@MarkEWaite ... would you be able to take a look at this?

I'm not a maintainer of the plugin. I don't feel qualified to review the pull request.

You can use the incremental build in your installation. That allows you to use the change immediately, without waiting for a release.