[JIRA] (JENKINS-61949) Configuration of action triggers in an Organization folder

[awong4@travelers.com (JIRA)]

Alan Wong created an issue

Jenkins / JENKINS-61949 Configuration of action triggers in an Organization folder Issue Type: New Feature Assignee: Aytunc BEKEN Components: multibranch-action-triggers-plugin Created: 2020-04-17 13:56 Priority: Minor Reporter: Alan Wong Recently, we have been able to setup handling of infrastructure teardowns by using the Pipeline Delete Event in this plugin with a multi-branch project. Unfortunately, now that we are looking to switch to an organization folder for automatic multi-branch project initialization, we have lost the ability to configure this plugin for child multi-branch projects. Specifically, the GitHub Organization project does not have options for action triggers, and the child multi-branch projects that it creates do not allow us to further configure actions independently. Could this feature be added? As a side issue, due to automating this across many repositories, it might be useful for the action triggers to be programmatically determined somehow (perhaps within the Jenkinsfile itself) rather than statically configured. Add Comment

This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)

[awong4@travelers.com (JIRA)]

Alan Wong updated an issue

Jenkins / JENKINS-61949 Configuration of action triggers in an Organization folder

Change By: Alan Wong

Recently, we have been able to setup handling of infrastructure teardowns by using the Pipeline Delete Event in this plugin with a multi-branch project. Unfortunately, now that we are looking to switch to an organization folder for automatic multi-branch project initialization, we have lost the ability to configure this plugin for child multi-branch projects. Specifically, the GitHub Organization project does not have options for action triggers, and the child multi-branch projects that it creates do not allow us to further configure actions independently. Could this feature be added?

As a side issue, due to automating this across many repositories, it might be useful for the action triggers to be programmatically determined somehow (perhaps within the Jenkinsfile itself) rather than statically configured. Or if not possible, maybe allow running against a branch of the repository that triggered the action?

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder Hi, Thanks for the feedback, As I understand there are three 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.

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN edited a comment on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

Hi, Thanks for the feedback, As I understand there are three 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.

Add Comment

[awong4@travelers.com (JIRA)]

Alan Wong commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

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).  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. 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). 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.

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

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.

Add Comment

[awong4@travelers.com (JIRA)]

Alan Wong commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

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.

Add Comment

[awong4@travelers.com (JIRA)]

Alan Wong edited a comment on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

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 :)

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

Cool! I will start working on this issue. Thanks

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN started work on JENKINS-61949

Change By: Aytunc BEKEN Status: Open In Progress

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN updated JENKINS-61949

Jenkins / JENKINS-61949

Configuration of action triggers in an Organization folder

Change By: Aytunc BEKEN Status: In Progress Review

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder Organization Folder support is released with version 1.8.3. I will be glad if you can provide feedback after using. Thanks

Add Comment

[awong4@travelers.com (JIRA)]

Alan Wong commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

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.

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

Interesting, my tests were okay, I will investigate. Could you please share below info ? Thanks. Jenkins Version GitGub Organization Plugin Version

Add Comment

[awong4@travelers.com (JIRA)]

Alan Wong commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

Jenkins Version: CloudBees Core Managed Master 2.204.2.2-rolling I believe the standalone organization plugin is deprecated in favor of the branch source plugin: - GitHub Branch Source Plugin:  2.6.0

Add Comment

[awong4@travelers.com (JIRA)]

Alan Wong edited a comment on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

- Jenkins Version: CloudBees Core Managed Master 2.204.2.2-rolling

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

Add Comment

[aytuncbeken.ab@gmail.com (JIRA)]

Aytunc BEKEN commented on JENKINS-61949

Re: Configuration of action triggers in an Organization folder

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.

Add Comment