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

Add ability to specify multiple deployment policy groups

XMLWordPrintable

      Current configuration options does not cover every possible deployment policy scenarios. For example:

      • Deploy when there is "SCM change" if build is started by build timer
      • Deploy regardless of "SCM change" if build is started by user

      In order to achive this, plugin should group "Deployment policy" and "SCM change" options together and allow user to specify as much group as possible.

      Another option is to extend deployment policy list for all possible scenarios. This should be easier to implement and understand. For example:

      • Started by user
      • Started by user (There is SCM change)
      • Started by build timer
      • Started by build timer (There is SCM change)
      • ...

      I will submit a PR with second approach soon. Which approach has better chance of acceptance?

        1. Screen Shot 2016-08-21 at 11.10.40.png
          Screen Shot 2016-08-21 at 11.10.40.png
          210 kB

          [JENKINS-37464] Add ability to specify multiple deployment policy groups

          Raphael CHAUMIER added a comment -

          Hi,

          Nice improvement.The second one seems a good compromise.

          Regards

          Raphael CHAUMIER added a comment - Hi, Nice improvement.The second one seems a good compromise. Regards

          Mustafa Ulu added a comment -

          Attaching my progress so far. I implemented an improved version of the second approach (similar to GitSCM plugin's extension approach)

          This will be backwards compatible and easily extendable.

          Mustafa Ulu added a comment - Attaching my progress so far. I implemented an improved version of the second approach (similar to GitSCM plugin's extension approach) This will be backwards compatible and easily extendable.

          Mustafa Ulu added a comment -

          Hi,

          Thanks for the comment.

          I didn't bother to support deprecated Causes in this implementation. Do people still use LegacyCodeCause and UserCause? If so I will add them.

          Regards.

          Mustafa Ulu added a comment - Hi, Thanks for the comment. I didn't bother to support deprecated Causes in this implementation. Do people still use LegacyCodeCause and UserCause? If so I will add them. Regards.

          Raphael CHAUMIER added a comment - - edited

          Thanks for your work,

          You can forget LegacyCodeCause and UserCause. I will add a notice in the release note of the future release. Can you check a job formerly configured with the follwoing causes is correctly loaded with the new version ?

          Regards,

          Raphael CHAUMIER added a comment - - edited Thanks for your work, You can forget LegacyCodeCause and UserCause. I will add a notice in the release note of the future release. Can you check a job formerly configured with the follwoing causes is correctly loaded with the new version ? Regards,

          Mustafa Ulu added a comment -

          I have submitted the PR. Tested with a job which is configured with all 8 causes. After the update, job is loaded successfully with 6 causes.

          Mustafa Ulu added a comment - I have submitted the PR. Tested with a job which is configured with all 8 causes. After the update, job is loaded successfully with 6 causes.

            raphc Raphael CHAUMIER
            mustafau Mustafa Ulu
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: