Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-61949

Configuration of action triggers in an Organization folder

    • 1.8.5

      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?

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

          Alan Wong created issue -
          Alan Wong made changes -
          Description Original: 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.
          New: 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?

          Aytunc BEKEN added a comment - - edited

          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.

          Aytunc BEKEN added a comment - - edited 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.

          Alan Wong added a comment -
          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.

          Alan Wong added a comment - 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.

          Aytunc BEKEN added a comment -

          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.

          Aytunc BEKEN added a comment - 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.

          Alan Wong added a comment - - edited

          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

          Alan Wong added a comment - - edited 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

          Aytunc BEKEN added a comment -

          Cool! I will start working on this issue.

          Thanks

          Aytunc BEKEN added a comment - Cool! I will start working on this issue. Thanks
          Aytunc BEKEN made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Aytunc BEKEN added a comment -

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

          Thanks

          Aytunc BEKEN added a comment - Organization Folder support is released with version 1.8.3. I will be glad if you can provide feedback after using. Thanks
          Aytunc BEKEN made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]

            aytuncbeken Aytunc BEKEN
            awong4travelers Alan Wong
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: