Hi,

Thanks for the feedback, As I understand there are four different topics. Let me summarize and ask some more questions to get some details.

1- GitHub Organization Folder: Organization folders was implemented, I need to check
2- Individual Configuration for Triggers Jobs in MultiBranch Jobs which are created by Organizational Folder: I am not sure how this works but I will check.
3- Could you please give some example about "programmatically" ?
4- "Or if not possible, maybe allow running against a branch of the repository that triggered the action?": I thought this before, this can create race condition between the plugin and multibranch plugin. For example, Trigger Job start when a new branch is discovered, If the branch job, which is also set as trigger job, is not indexed yet other branch jobs will fail.

1. Our company has been primarily using Organization folders due to ease of administration (rather than either manually creating multi-branch projects or using Job DSL).
2.  When an Org folder scans a compatible repository, it automatically creates a multi-branch project based on settings in the Org folder settings. As far as I can tell, these multi-branch projects do not allow further alterations independent from the Org folder.
3. Because the multi-branch projects are not alterable, if action triggers are added to the Org folder, it might need to be setup to allow each repository to determine the values (otherwise, every multi-branch project will have the same values).
4. I am actually using this method right now to keep everything inside the same repository, it is just targeting the /develop branch for now, but it will be updated to /master at some point. But I am only using this for deletion, not creation. I can definitely see that creation would pose a huge issue with race conditions.

Thanks for the comments.
So what I can do is;

1 - Enable Action tiggers in Github organization Folder. This configuration will automatically set to underlying multibranch jobs.
2 and 3 - I can pass the SCM/Repository value to Triggered job. By this, Triggered job can be customized to take different actions on different repositories/SCMs.
4 - If this is not a very big blocker, I would like to keep same as current. Preventing this kind of race condition is important.

Thank you very much for the response. Being able to use this with organization folders will be a huge time saver.

2 and 3 - Would this be almost the same as just passing the Jenkins project name (SOURCE_PROJECT_FULL_NAME or SOURCE_PROJECT_NAME)? Actually, with the existing project name I could solve for 4 by simply executing the alternate pipeline from a centralized pipeline for action triggers. Using this method would remove the need for 2, 3, and 4.

Based on this, please ignore 2, 3, and 4

Cool! I will start working on this issue.

Thanks

Organization Folder support is released with version 1.8.3.
I will be glad if you can provide feedback after using.

Thanks

I just tried the updated version (1.8.3) in our sandbox region and found the following things:

• When setting up the organization and filling out the new organization Pipeline Action Triggers section, these parameters are not forwarded to downstream projects after the organization scan. Attempting to trigger a delete event either through Scan Repository Now or Scan Organization Now did not appear to do anything.
• When updating the organization configuration, settings were not updated in downstream projects. They remained in their default settings on both initial creation and on update.

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.