[JIRA] (JENKINS-30383) AbstractSynchronousNonBlockingStepExecution should allow restart of idempotent steps

2017-02-17 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-30383  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: AbstractSynchronousNonBlockingStepExecution should allow restart of idempotent steps   
 

  
 
 
 
 

 
 Same thing with SCMStep. Are you considering it? Jesse Glick James Nord  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-40628) Post build action not performed on Safe Restart

2016-12-22 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40628  
 
 
  Post build action not performed on Safe Restart   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Roman Kulikov  
 
 
Components: 
 parallels-desktop-plugin  
 
 
Created: 
 2016/Dec/22 11:13 AM  
 
 
Environment: 
 Jenkins ver. 1.651.1, Parallels Desktop Cloud plugin 0.3  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 Anna Tikhonova  
 

  
 
 
 
 

 
 VM post build action is not performed when initiating Safe Restart https://wiki.jenkins-ci.org/display/JENKINS/SafeRestart+Plugin. I've configured the plugin to suspend VM after it has finished executing jobs. With Safe Restart initiated, Jenkins waits for all running jobs to end and, once they're finished, restarts. Jenkins waits for jobs running on cloud slaves (VMs), disconnects and removes the slave, but the suspend action is not performed. As the result, those VMs keep running.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

 

[JIRA] (JENKINS-40685) Operation timed out when launching VM slave

2016-12-27 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40685  
 
 
  Operation timed out when launching VM slave   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Roman Kulikov  
 
 
Components: 
 parallels-desktop-plugin  
 
 
Created: 
 2016/Dec/27 1:20 PM  
 
 
Environment: 
 Jenkins ver. 1.651.1, parallels-desktop-plugin 0.3  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Anna Tikhonova  
 

  
 
 
 
 

 
 I have the plugin configured to suspend VMs when jobs finished. I noticed that sometimes starting a VM slave in Parallels Desktop takes way too long for Jenkins, so the master stops attempts to connect to the slave and takes it offline with 'This node is offline because Jenkins failed to launch the slave agent on it' message. In the slave log there's 

 

[12/27/16 14:36:50] [SSH] Opening SSH connection to VMHostname:22.
Operation timed out
ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins.
java.lang.IllegalStateException: Connection is not established!
 

 I can launch the slave manually, and then everything is fine: the waiting jobs run there, the slave is suspended and removed from Jenkins. Looks like this happens because the timeout for VM startup is set to 60 seconds in ParallelsDesktopConnectorSlaveComputer.java:getVmIPAddress(). Probably, it should have a bigger timeout and check for VM status in this loop.  
 

  
 
 
   

[JIRA] (JENKINS-40685) Operation timed out when launching VM slave

2016-12-27 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-40685  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Operation timed out when launching VM slave   
 

  
 
 
 
 

 
 Roman Kulikov I have changed the timeout to 600 seconds in my build, which I think is way too much. I cannot reproduce this slow startup anymore to check the timing, nor I can read parallels.log. It wasn't that bad, just a couple of minutes though. Up to 3 minutes might work for us. If it takes longer, we'll know there's a real problem with the machine because the jobs will be waiting.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-40691) Do not start new VMs when there're not enough resources available

2016-12-27 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40691  
 
 
  Do not start new VMs when there're not enough resources available   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Roman Kulikov  
 
 
Components: 
 parallels-desktop-plugin  
 
 
Created: 
 2016/Dec/27 5:14 PM  
 
 
Environment: 
 Jenkins ver. 1.651.1, parallels-desktop-plugin 0.3  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Anna Tikhonova  
 

  
 
 
 
 

 
 As of ver 0.3, parallels-desktop-plugin provisions as many VMs as Jenkins master requests at a time. This results in multiple VMs running simultaneously despite their configuration, which: a) Will be slower than expected b) Might result in something like described in JENKINS-40685 (it happened exactly when Parallels Desktop was starting up two VMs with the total memory greater than the host memory – the hardcoded timeout wasn't enough) The suggestion is to implement a pre-provisioning check that the total resources required by the multiple VMs to be provisioned are not greater that what the host has. The check could be optional (a checkbox in Cloud configuration).  
 

  
 
 
 
 

 
 
 

 
 
  

[JIRA] (JENKINS-47978) Lightweight checkout not working for branches that contain forward slash '/'

2018-04-09 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-47978  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout not working for branches that contain forward slash '/'   
 

  
 
 
 
 

 
 I can confirm that the issue is not in Bitbucket branch source plugin. I have tested 2.2.10 (which is the latest at the time of writing) with Bitbucket Server and Jenkinsfile placed in build/test.jenkinsfile in my repository. Flawless.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-47978) Lightweight checkout not working for branches that contain forward slash '/'

2018-04-09 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova edited a comment on  JENKINS-47978  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout not working for branches that contain forward slash '/'   
 

  
 
 
 
 

 
 I can confirm that  the issue  there  is  not  an issue  in Bitbucket branch source plugin. I have tested 2.2.10 (which is the latest at the time of writing) with Bitbucket Server and Jenkinsfile placed in build/test.jenkinsfile in my repository.  Flawless  With 'master' branch it is flawless .  However, when I put it to branch 'feature/test', in the console output I have:{code:java}Lightweight checkout support not available, falling back to full checkout.Checking out git ssh://localhost:7999/bitbucket/~atikhonova/test.git into /var/lib/jenkins/workspace/test@script to read build/test.jenkinsfile{code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-47978) Lightweight checkout not working for branches that contain forward slash '/'

2018-04-09 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova edited a comment on  JENKINS-47978  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout not working for branches that contain forward slash '/'   
 

  
 
 
 
 

 
 I can confirm that  the original issue is still  there . I don't know if it  is  an issue  in Bitbucket branch source plugin  or elsewhere . I have tested 2.2.10 (which is the latest at the time of writing) with Bitbucket Server and Jenkinsfile placed in build/test.jenkinsfile in my repository. With 'master' branch it is flawless. However, when I put it to branch 'feature/test', in the console output I have:{code:java}Lightweight checkout support not available, falling back to full checkout.Checking out git ssh://localhost:7999/bitbucket/~atikhonova/test.git into /var/lib/jenkins/workspace/test@script to read build/test.jenkinsfile{code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-43894) Environment variables not resolved in Pipeline SCM -> Advanced clone behaviours -> Path of the reference repo

2018-04-11 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-43894  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables not resolved in Pipeline SCM -> Advanced clone behaviours -> Path of the reference repo   
 

  
 
 
 
 

 
 Steven Foster For cloud slaves you will need to support setting environment variables via Node Properties in Jenkins. That should be implemented in a plugin that provides those slaves. The patch above should work for environment variables set on an agent.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-47978) Lightweight checkout not working for branches that contain forward slash '/'

2018-04-16 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-47978  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout not working for branches that contain forward slash '/'   
 

  
 
 
 
 

 
 The workaround is to put 'refs/heads/feature/test' in Branch Specifier field of Git SCM. Not 'feature/test', not '*/feature/test'. You have to specify your git ref at full as this is the only supported case. See the breaking code in git-plugin (src/main/java//jenkins/plugins/git/GitSCMFileSystem.java): 

 

@Extension(ordinal = Short.MIN_VALUE)
public static class BuilderImpl extends SCMFileSystem.Builder {

  @Override
  public boolean supports(SCM source) {
return source instanceof GitSCM
  && ((GitSCM) source).getUserRemoteConfigs().size() == 1
  && ((GitSCM) source).getBranches().size() == 1
  && ((GitSCM) source).getBranches().get(0).getName().matches(
  "^((\\Q" + Constants.R_HEADS + "\\E.*)|([^/]+)|(\\*/[^/*]+(/[^/*]+)*))$"// HERE !!
);
  // we only support where the branch spec is obvious 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-47978) Lightweight checkout not working for branches that contain forward slash '/'

2018-04-16 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova edited a comment on  JENKINS-47978  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout not working for branches that contain forward slash '/'   
 

  
 
 
 
 

 
 The workaround is to put 'refs/heads/feature/test' in Branch Specifier field of Git SCM. Not 'feature/test', not '*/feature/test'. You have to specify your git ref at full as this is the only supported case. See the breaking code in git-plugin (src/main/java//jenkins/plugins/git/GitSCMFileSystem.java):{code:java}@Extension(ordinal = Short.MIN_VALUE)public static class BuilderImpl extends SCMFileSystem.Builder {  @Override  public boolean supports(SCM source) {return source instanceof GitSCM  && ((GitSCM) source).getUserRemoteConfigs().size() == 1  && ((GitSCM) source).getBranches().size() == 1  && ((GitSCM) source).getBranches().get(0).getName().matches(  "^((\\Q" + Constants.R_HEADS + "\\E.*)|([^/]+)|(\\*/[^/*]+(/[^/*]+)*))$"// HERE !!);  // we only support where the branch spec is obvious{code} I think this simple implementation is good and the only issue here is the match failing silently. Probably, this method should put a warning to the Console why lightweight checkout failed.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-47978) Lightweight checkout not working for branches that contain forward slash '/'

2018-04-16 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova edited a comment on  JENKINS-47978  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Lightweight checkout not working for branches that contain forward slash '/'   
 

  
 
 
 
 

 
 The workaround is to put 'refs/heads/feature/test' in Branch Specifier field of Git SCM. Not 'feature/test', not '*/feature/test'. You have to specify your git ref at full as this is the only supported case. See the breaking code in git-plugin (src/main/java//jenkins/plugins/git/GitSCMFileSystem.java):{code:java}@Extension(ordinal = Short.MIN_VALUE)public static class BuilderImpl extends SCMFileSystem.Builder {  @Override  public boolean supports(SCM source) {return source instanceof GitSCM  && ((GitSCM) source).getUserRemoteConfigs().size() == 1  && ((GitSCM) source).getBranches().size() == 1  && ((GitSCM) source).getBranches().get(0).getName().matches(  "^((\\Q" + Constants.R_HEADS + "\\E.*)|([^/]+)|(\\*/[^/*]+(/[^/*]+)*))$"// HERE !!);  // we only support where the branch spec is obvious{code}I think this simple implementation is good and the only issue here is the match failing silently. Probably, this method should put a warning to the Console  explaining  why lightweight checkout failed.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-27299) Refactor Disable Build feature out of AbstractProject for Pipeline Compatibility

2017-03-29 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-27299  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Refactor Disable Build feature out of AbstractProject for Pipeline Compatibility   
 

  
 
 
 
 

 
 Having Disable Build/Project feature for pipelines would be somewhat a workaround for Safe Restart, since Safe Restart is broken for many pipeline steps. It's a pain to maintain Jenkins having many lng pipelines. Keeps us away from droping Build Flow plugin completely in favour of pipeline.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-47098) Generate Pipeline Script for "Update relevant issue" create garbage

2018-02-26 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-47098  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Generate Pipeline Script for "Update relevant issue" create garbage   
 

  
 
 
 
 

 
 Reproducible for Jenkins 2.89, pipeline plugin 2.5 and jira-plugin 2.5.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-43894) Environment variables not resolved in Pipeline SCM -> Advanced clone behaviours -> Path of the reference repo

2018-03-15 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-43894  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Environment variables not resolved in Pipeline SCM -> Advanced clone behaviours -> Path of the reference repo   
 

  
 
 
 
 

 
 Patrick Ruckstuhl So 'scm' extensions can be overridden actually... awesome tip, thanks! I have submitted a PR to git-plugin some time ago: https://github.com/jenkinsci/git-plugin/pull/575. No one who can merge seems to have time / be interested in it. I have just built the plugin with my patch and installed it in my instance.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-33046) Next Build Number plugin doesn't work for Workflow or Multi-branch Workflow jobs

2016-08-22 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-33046  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Next Build Number plugin doesn't work for Workflow or Multi-branch Workflow jobs   
 

  
 
 
 
 

 
 Alexander Komarov Yep I couldn't agree more that it's absolutely unnecessary to set custom build numbers on feature/bugfix/hotfix jobs, but what about release branches? How should they be managed by design in Multibranch pipeline projects? Could you please suggest/shed some light on the intended workflow for them? The whole multibranch pipeline feature is super hot and we'd absolutely love to switch to it entirely, but still we'd like to keep the build number part of our workflow. Let me describe what it's like and why we want it. Assume our current master build number is N. We branch each release out of master and bump master build numbers to N + M, where M is a "window" that should be enough for this release branch lifetime. We do not build releases on each commit but every 4 hours, which makes it easy to make a fine estimate for M. This scheme makes build comparison straight-forward, by their build numbers. We can track where the branching has happened and determine where in commit history the particular build belongs (approx.) just by looking at its build number. Convenient because you can see if a patch was included into that particular build. Also, as Bryden Oliver has mentioned, build numbers might be visible to customers (which is true in our case as well, but we don't set them to something like '43p1'; we just bump the standard numerical build numbers in Jenkins), so I suppose many would like an opportunity to control them. Please, for the sake of never failing build, help.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

   

[JIRA] (JENKINS-30019) It does not work with Jenkins Workflow jobs

2016-08-22 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-30019  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: It does not work with Jenkins Workflow jobs   
 

  
 
 
 
 

 
 +1 for Multibranch Pipeline support! Prevents us from switching to multibranch pipelines completely.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 

  
 

   





-- 
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] (JENKINS-30019) It does not work with Jenkins Workflow jobs

2016-08-22 Thread atikhon...@parallels.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Anna Tikhonova commented on  JENKINS-30019  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: It does not work with Jenkins Workflow jobs   
 

  
 
 
 
 

 
 Jesse Glick Thanks! Setting custom build numbers makes sense for release branches sometimes. I've described the problem in JENKINS-33046. We want to bump master build numbers every time we branch a release out of it. 

 

The whole multibranch pipeline feature is super hot and we'd absolutely love to switch to it entirely, but still we'd like to keep the build number part of our workflow. Let me describe what it's like and why we want it. Assume our current master build number is N. We branch each release out of master and bump master build numbers to N + M, where M is a "window" that should be enough for this release branch lifetime. We do not build releases on each commit but every 4 hours, which makes it easy to make a fine estimate for M. This scheme makes build comparison straight-forward, by their build numbers. We can track where the branching has happened and determine where in commit history the particular build belongs (approx.) just by looking at its build number. Convenient because you can see if a patch was included into that particular build.
Also, as Bryden Oliver has mentioned, build numbers might be visible to customers (which is true in our case as well, but we don't set them to something like '43p1'; we just bump the standard numerical build numbers in Jenkins), so I suppose many would like an opportunity to control them.
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)