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

Prevent transition if status wouldn't change

    Details

    • Similar Issues:

      Description

      We are using the jira ext plugin to set JIRA issues to the status "Live" when they get deployed. We often have the case where the status has been set manually before. In such cases it would be great, if there was a way to prevent the plugin to trigger the transition again, if the Before status and After status are the same.

        Attachments

        1. board.png
          board.png
          246 kB
        2. email.pdf
          44 kB
        3. screenshot.png
          screenshot.png
          143 kB
        4. workflow.png
          workflow.png
          74 kB

          Activity

          Hide
          dalvizu Dan Alvizu added a comment -

          Hi, can you describe the states and workflows so I can understand the problem better.

          For example, do you have:

          open -> in progress -> closed

          Where 'start work' is the transition name to move from open to in-progress, and you want to use that only if the transition is 'open', but not 'in progress'?

          If so - what is the behavior you see today?

          Show
          dalvizu Dan Alvizu added a comment - Hi, can you describe the states and workflows so I can understand the problem better. For example, do you have: open -> in progress -> closed Where 'start work' is the transition name to move from open to in-progress, and you want to use that only if the transition is 'open', but not 'in progress'? If so - what is the behavior you see today?
          Hide
          flaimo flaimo flaimo added a comment -

          I have attached the workflow (jira agile workflow) and board as screenshots.

          The basic use case, which already works, looks like this:
          1) Developer finished his code review and deployment tasks by merging into the master branch and manually changes the ticket status to "done"
          2) Jenkins job pushes the new release to the live servers
          3) The plugin changes the status of the ticket from "done" to "live" → Because of jira e-mail subscriptions the product owners get an email that the status has changed to "live"

          Now there are two corner cases which cause unnecessary status transitions:
          a) The developer set the status to "live" manually by accident before the jenkins job was triggered
          b) Some tickets, that are part of a base library, are checked out with every deploy. This means the plugin triggers the transition to "live" for some tickets over and over again, which were already set to "live" by a previous job.

          The problem is, that in both cases our product owners get status update mails for tickets that have already been set to "live" once. The problem could easily be solved, if there was an option in the plugin that, if activated, would check the status of every ticket it is about to do a transition on and if the current status is the same as the status after the transition, it should just skip the issue. So in the two cases above transitions from "live" to "live" should be skipped.

          Show
          flaimo flaimo flaimo added a comment - I have attached the workflow (jira agile workflow) and board as screenshots. The basic use case, which already works, looks like this: 1) Developer finished his code review and deployment tasks by merging into the master branch and manually changes the ticket status to "done" 2) Jenkins job pushes the new release to the live servers 3) The plugin changes the status of the ticket from "done" to "live" → Because of jira e-mail subscriptions the product owners get an email that the status has changed to "live" Now there are two corner cases which cause unnecessary status transitions: a) The developer set the status to "live" manually by accident before the jenkins job was triggered b) Some tickets, that are part of a base library, are checked out with every deploy. This means the plugin triggers the transition to "live" for some tickets over and over again, which were already set to "live" by a previous job. The problem is, that in both cases our product owners get status update mails for tickets that have already been set to "live" once. The problem could easily be solved, if there was an option in the plugin that, if activated, would check the status of every ticket it is about to do a transition on and if the current status is the same as the status after the transition, it should just skip the issue. So in the two cases above transitions from "live" to "live" should be skipped.
          Hide
          dalvizu Dan Alvizu added a comment -

          Ah okay, interesting, so you can transition the ticket to "Live" when it is already "Live". I hadn't considered a workflow having transitions to the same state.

          Show
          dalvizu Dan Alvizu added a comment - Ah okay, interesting, so you can transition the ticket to "Live" when it is already "Live". I hadn't considered a workflow having transitions to the same state.
          Hide
          flaimo flaimo flaimo added a comment -

          Those "every state to every state" transitions are the default, if you create a new project with a Kanban or Scrum template in JIRA Software.

          https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/configuring-columns/using-jira-agile-simplified-workflow

          Show
          flaimo flaimo flaimo added a comment - Those "every state to every state" transitions are the default, if you create a new project with a Kanban or Scrum template in JIRA Software. https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/configuring-columns/using-jira-agile-simplified-workflow

            People

            • Assignee:
              dalvizu Dan Alvizu
              Reporter:
              flaimo flaimo flaimo
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: