It would be great to have a new Promotion API plugin which includes shareable functionality from the Promoted Builds plugin. It would help us to reuse the plugin on instances without AbstractProject and Freestyle builds in the future

          [JENKINS-60500] Break out the Promotion API plugin

          Oleg Nenashev added a comment -

          This is a draft pull request which explores ways to split the plugin to two ones. Promotion's Permission entities look to be a major showstopper on this way, but just in case.

          Research summary: Promotion is unsolvable knot if we want to retain binary compatibility

          • Permission engine in Jenkins relies on Permission Groups, which reference class explicitly. In order to retain Permissions Promotion class has to be in promotion API
          • Promotion is also a persisted object on the disk. We could use XStream features to rename the class and move all run entries. It would split the class to two... somehow
          • Promotion and PromotionProcess are a part of the API used by other plugins. Class Renaming will not help unless full interface is retained. It includes fields, and hence it has to be class inheritance. Hence we have to keep public abstract class PromotionProcess extends AbstractProject<PromotionProcess,Promotion> implements Saveable, Describable<PromotionProcess> in promotion API with class relocation
          • AbstractClass#getBuildClass() }}requires an exact class. And this is the end of the story for us, because the template declares {{PromotionProcess, and hence splitting classes is not possible.

          So it is not possible to retain binary compatibility and to avoid pbreaking changes, at least without sophisticated Jenkins core patches.

          Oleg Nenashev added a comment - This is a draft pull request which explores ways to split the plugin to two ones.  Promotion 's Permission entities look to be a major showstopper on this way, but just in case. Research summary:  Promotion  is unsolvable knot if we want to retain binary compatibility Permission engine in Jenkins relies on Permission Groups, which reference class explicitly. In order to retain Permissions  Promotion  class has to be in promotion API Promotion  is also a persisted object on the disk. We could use XStream features to rename the class and move all run entries. It would split the class to two... somehow Promotion  and  PromotionProcess  are a part of the API used by other plugins. Class Renaming will not help unless full interface is retained. It includes fields, and hence it has to be class inheritance. Hence we have to keep  public abstract class PromotionProcess extends AbstractProject<PromotionProcess,Promotion> implements Saveable, Describable<PromotionProcess>  in promotion API with class relocation AbstractClass#getBuildClass() }}requires an exact class. And this is the end of the story for us, because the template declares {{PromotionProcess , and hence splitting classes is not possible. So it is not possible to retain binary compatibility and to avoid pbreaking changes, at least without sophisticated Jenkins core patches.

          Oleg Nenashev added a comment -

          My plan is to do refactoring as a single plugin at the moment

          Oleg Nenashev added a comment - My plan is to do refactoring as a single plugin at the moment

            oleg_nenashev Oleg Nenashev
            oleg_nenashev Oleg Nenashev
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: