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

Declarative should provide an easy way to disable/enable some steps in an PR context or not

XMLWordPrintable

      When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

      PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

      Maybe this be globally enabled/disabled by default though the new options block.

      Like:

      options {
   notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
}

      And possibly be overridable per step, like:

      notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
   sh "deploy-to-production.sh"
}

      For when and usual stage deactivations:

      when {
    branch CHANGE_REQUEST
}

      WDYT?

      Thanks!

          [JENKINS-40898] Declarative should provide an easy way to disable/enable some steps in an PR context or not

          Baptiste Mathus created issue -
          Baptiste Mathus made changes -
          Summary Original: Declarative should provide an easy to disable/enable some steps in an PR context or not New: Declarative should provide an easy way to disable/enable some steps in an PR context or not
          Baptiste Mathus made changes -
          Description Original: When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR.

          PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

          Maybe this be globally enabled/disabled by default though the new {{options}} block.

          Like:

          {code:java}
          options {
             notifyOnPullRequest = true // I would argue that we should be opinionated and put it with a default of false
          }
          {code}


          And possibly be overridable per step, like:

          {code:java}
          notOnPR {
             mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
          }
          {code}

          WDYT?

          Thanks!           		New: When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

          PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

          Maybe this be globally enabled/disabled by default though the new {{options}} block.

          Like:

          {code:java}
          options {
             notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
          }
          {code}

          And possibly be overridable per step, like:

          {code:java}
          notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
             mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
          }
          {code}

          For when and usual stage deactivations:

          {code}
          when {
             onChangeRequest
          }
          {code}

          WDYT?

          Thanks!
          Baptiste Mathus made changes -
          Description Original: When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

          PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

          Maybe this be globally enabled/disabled by default though the new {{options}} block.

          Like:

          {code:java}
          options {
             notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
          }
          {code}

          And possibly be overridable per step, like:

          {code:java}
          notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
             mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
          }
          {code}

          For when and usual stage deactivations:

          {code}
          when {
             onChangeRequest
          }
          {code}

          WDYT?

          Thanks!           		New: When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

          PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

          Maybe this be globally enabled/disabled by default though the new {{options}} block.

          Like:

          {code:java}
          options {
             notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
          }
          {code}

          And possibly be overridable per step, like:

          {code:java}
          notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
             mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
          }
          {code}

          For when and usual stage deactivations:

          {code}
          when {
              branch CHANGE_REQUEST
          }
          {code}

          WDYT?

          Thanks!
          Baptiste Mathus made changes -
          Description Original: When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

          PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

          Maybe this be globally enabled/disabled by default though the new {{options}} block.

          Like:

          {code:java}
          options {
             notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
          }
          {code}

          And possibly be overridable per step, like:

          {code:java}
          notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
             mail to: NOTIFICATION_TARGET, subject:"FAILURE: ${currentBuild.fullDisplayName}", body: "Boo, we failed"
          }
          {code}

          For when and usual stage deactivations:

          {code}
          when {
              branch CHANGE_REQUEST
          }
          {code}

          WDYT?

          Thanks!           		New: When writing a Jenkinsfile, if you have email notifications, or notifications in general, this probably does not make sense to send those when building a PR. Same goes for actual deployments or touching real environments by any mean.

          PR are reviewed through GitHub, have a build status there, and so on. So by default, sending emails to maintainers creates unnecessary noise.

          Maybe this be globally enabled/disabled by default though the new {{options}} block.

          Like:

          {code:java}
          options {
             notifyOnChangeRequest = true // I would argue that we should be opinionated and put it with a default of false
          }
          {code}

          And possibly be overridable per step, like:

          {code:java}
          notOnChangeRequest { // PR on GitHub & Bitbucket, patchset on Gerrit, Review Request in ReviewBoard...
             sh "deploy-to-production.sh"
          }
          {code}

          For when and usual stage deactivations:

          {code}
          when {
              branch CHANGE_REQUEST
          }
          {code}

          WDYT?

          Thanks!
          Andrew Bayer made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Baptiste Mathus made changes -
          Link New: This issue relates to JENKINS-42688 [ JENKINS-42688 ]
          CloudBees Inc. made changes -
          Remote Link New: This issue links to "CloudBees Internal OSS-1812 (Web Link)" [ 18556 ]
          Liam Newman made changes -
          Status Original: Resolved [ 5 ] New: Closed [ 6 ]

            abayer Andrew Bayer
            batmat Baptiste Mathus
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: