[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Jesse Glick reopened an issue Need to review behavior in the special case of SubversionSCM with distinct locations for the Workflow script vs. what is passed to checkout. getKey() is implemented to take locations into account, so these ought to be considered distinct SCMs, but perhaps they are being conflated somehow. you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds. That is true of any CI system in which developers are allowed to push directly to an integration branch (like trunk). The only way to prevent that is to gate all commits by CI status, as Workflow: Multibranch would help you do. (Currently there is no plugin for it to automatically merge branches that pass.) Jenkins / JENKINS-31389 SVN changelog on wrong build Change By: Jesse Glick Resolution: Not A Defect Status: Resolved Reopened Assignee: Jesse Glick Add Comment
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Martin Vehovsky commented on JENKINS-31389 Re: SVN changelog on wrong build No, no, no they definitely could not! That is why I specify SCM path in job config as for example /trunk/tools/jenkins/worflow. Changes in that and only that folder could influence the workflow script itself. Imagine that your build will fail and you want to investigate the reason. You will check the changelog for this build and no you are not finished you will have to check all the other builds that did NOTHING but containing changelog informations that was really taken to account in this build. Even more, you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds. Looks to me that you are just trying to justify current implementation. Which is very cumbersome for users of your product. This should be reopened. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Jesse Glick commented on JENKINS-31389 Re: SVN changelog on wrong build we use second option, just because having job definitions in SCM is quite convenient Right. So in that case it is correct that build #2 shows SVN changes #22–23: those may in fact have included modifications to the Workflow script which may have affected how build #2 ran. you know nothing about what changes did actually make it into your build Of course you do. As with any series of builds of a project using an SCM checking out from a specific branch, a build is assumed to include all changes listed in earlier builds, plus whatever is listed in its own changelog. Whether some of the earlier builds ran all the way to completion, or terminated early, is not relevant. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Martin Vehovsky edited a comment on JENKINS-31389 Re: SVN changelog on wrong build How can you close this, saying this inconsistent behaviour is ok??Off course we use second option, just because having job definitions in SCM is quite convenient.I have to say, that it 's pretty crappy behaviour, you can't say nothing about your build with certainty as you know NOTHING about what what changes did actually made it to your build!Really really disappointed about this! Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Martin Vehovsky commented on JENKINS-31389 Re: SVN changelog on wrong build How can you close this, saying this inconsistent behaviour is ok?? Off course we use second option, just because having job definitions in SCM is quite convenient. I have to say, that it pretty crappy behaviour, you can't say nothing about your build with certainty as you know NOTHING about what what changes did actually made it to your build! Really really disappointed about this! Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Jesse Glick resolved as Not A Defect If you have a simple inline script definition, build #3 will show SVN changes #22–25, since that is what the checkout scm: … step will be updating. If you are using a script loaded from SCM (and that SCM is in fact the same Subversion repository as the checkout step is using), then the first update will occur before the defined script even starts. Thus build #2 will show SVN changes #22–23 and build #3 will show changes #24–25. Similarly, if you are using a multibranch workflow, the checkout to get Jenkinsfile occurs before the script starts, so each build will be listed as including some SVN changes. Jenkins / JENKINS-31389 SVN changelog on wrong build Change By: Jesse Glick Status: Open Resolved Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this
[JIRA] [workflow-plugin] (JENKINS-31389) SVN changelog on wrong build
Title: Message Title Jesse Glick updated an issue Jenkins / JENKINS-31389 SVN changelog on wrong build Change By: Jesse Glick Summary: Workflow plugin - SVN changelog on wrong build Component/s: core Priority: Critical Major Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
