[JIRA] (JENKINS-30383) AbstractSynchronousNonBlockingStepExecution should allow restart of idempotent steps
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
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
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
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
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 '/'
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 '/'
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 '/'
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
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 '/'
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 '/'
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 '/'
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
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
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
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
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
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
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)