Interesting, my tests were okay, I will investigate.
Could you please share below info ? Thanks.

Jenkins Version
GitGub Organization Plugin Version

I believe the standalone organization plugin is deprecated in favor of the branch source plugin:

• Jenkins Version: CloudBees Core Managed Master 2.204.2.2-rolling
• GitHub Branch Source Plugin:  2.6.0

Hi,

I fixed the issue with GitHub Organization Folder. Also tested with real repositories in GitHub.
This fix is released with 1.8.4 version.

I will be glad if you can provide feedback.
Thanks.

I did some testing and found the following things:

• When testing, I used a single repository and hard coded the Pipeline Delete Event (for the org) to be the "sandbox-delete" branch of this same repository. I created and deleted a new branch called "sandbox-delete-test". Once I had verified that the branch is marked for deletion in Jenkins, I ran "Scan Repository Now" to force the event, and both the scan and the delete appear to be deadlocked permanently.
  • Note that I did also try adding the "sandbox-delete" branch to the ignored line (along with master and develop) but it still locks. I was able to use this pattern without issue within a regular multi-branch build with the delete trigger.
• Using a job outside of the org for a delete event worked fine. I will probably use this pattern in production (using a job outside of the org to call the job inside of the org so that the repository can be in charge of how its own delete happens).
• Updating the values of the action triggers in the organization did not update any existing repositories in the organization. So if I set the delete event to "job1" and let the repository scan finish, updating the event to "job2" did not change the event in the existing repository. It was still "job1" (even after another scan).
  • I tested this also with other options (specifically "Days to keep old items" and it propagated correctly.

Thanks for the feedback! My comments are below.

1- I will try to generate same situation. However defining trigger job in the same repository which creates the same job, is always risky. I am not sure if I can find a solution for that.
3- Fixed the issue, sorry for the inconvenience. I will comment to this issue with the release number.

Release with version 1.8.5

Thank you so much for the update.

I just tried 1.8.5 on our sandbox Jenkins and it works perfectly (updating the delete job parameter at the org level propagated correctly). For allowing a repo to handle its own deletions, I'm now using the following Jenkinsfile:

pipeline {
    agent any
    stages {
        stage('Delete') {
            steps {
                script {
                    if (env.SOURCE_PROJECT_FULL_NAME?.trim()) {
                        build job: env.SOURCE_PROJECT_FULL_NAME.replaceAll(/\/[^\/]+$/, '/branch-name'), parameters: [
                            string(name: 'SOURCE_PROJECT_NAME', value: env.SOURCE_PROJECT_NAME),
                            string(name: 'SOURCE_PROJECT_FULL_NAME', value: env.SOURCE_PROJECT_FULL_NAME)
                        ]
                    }
                }
            }
        }
    }
}

I was able to setup a preliminary test which worked fine, with no dead locks so far.

You are welcome!

Thanks for sharing the job. Nice implementation. I think you should publish this, probably lots of people will look for a similar solution.

If you do not have any objections, I will close the ticket soon.

No objections here. Thank you.

Thank you! for your contribution and all your efforts.