[JIRA] [lockable-resources-plugin] (JENKINS-34433) pipeline lock does not retry
Title: Message Title Xavier Van Dessel updated an issue Jenkins / JENKINS-34433 pipeline lock does not retry Change By: Xavier Van Dessel Component/s: lockable-resources-plugin 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] [pipeline-utility-steps-plugin] (JENKINS-34433) pipeline lock does not retry
Title: Message Title
Xavier Van Dessel created an issue
Jenkins / JENKINS-34433
pipeline lock does not retry
Issue Type:
Bug
Assignee:
rsandell
Components:
pipeline-utility-steps-plugin
Created:
2016/Apr/25 3:35 PM
Environment:
Jenkins 1.642.4.2 with Cloudbees Enterprise 15.11 Lockable Resource plugin 1.8
Priority:
Major
Reporter:
Xavier Van Dessel
Add a lockable resource named "test_res"
Add a pipeline job with only this code:
node {
lock('test_res') { echo 'locked' }
echo 'unlocked' }
Run this job. It should work fine.
Now perform a manual reserve of the resource via the lockable resource interface. Start the job again. It correctly waits for the resource: [Pipeline] node { [Pipeline] Lock shared resource : Start Trying to acquire lock on [test_res] [test_res] is locked, waiting...
Now go back to the Lockable Resource user interface. Manually unlock the resource.
Expected result: the locked job should retry the lock, see that it has been freed, continue (locking the resource and freeing it) and finish correctly.
[JIRA] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Xavier Van Dessel commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated I fully agree with Mark and Sam comments regarding different protocols between main and submodule. Most installations will use a homogenuous approach. I would however recommend to add this requirement/limitation in the info box that opens for the new submodule authentication option. There are however still other (less commonly used) protocols which may require testing. Git supports ftp as a protocol using passwords. I have no idea whether the code changes between http(s) and ftp justify an explicit test setup. My test setup (BitBucket based) does not support it. 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] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Xavier Van Dessel commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated Mark, Indeed, the original test (SSH with keys switched to http(s) with passwords) failed. But I'm not saying it has to do with the code of the Jenkins plugins. Situation 1 uses an SSH key. Hence, the ssh call to expand the submodule only disposes of the userid/password combination that worked fine on the main http(s) call. But the ssh engine does not share the same user an psw db with the BitBucket http(s) server on my system, which explains the failure. I would even say more: the other way arround would certainly never work: if the main repo uses an SSH key, but the submodule is referenced as a http(s) link, then it can never work (unless the http(s) server has no security) simply because an SSH key would not work on a http(s) link AFAIK. Given that the git protocol nor the local file protocol require any kind of authentication, these 2 are unaffected by this ticket. Thus if keys are used, all repo access MUST use the SSH protocol otherwise the git client has no credentials at all to use. This gives the below overview: Auth type: SSH KEY main repo=ssh, submodule=ssh : tested OK (my first test report) Auth type: User & PSW main repo=http(s), submodule=http(s) : tested OK (my second test report) main repo=ssh, submodule=ssh : to test main repo=http(s), submodule=ssh : to test main repo=ssh, submodule=http(s) : to test Has anybody validated any such combination yet? 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] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Xavier Van Dessel commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated The Beta worked for me also, while it failed before with auth issues. Jenkins: 1.635 running on Linux Fedora 20 Target slave: Windows, running native Windows GIT stack (no cygwin) git repository accessed via SSH on an Atlassian BitBucket server (aka Stash) on a Linux server using an SSH key from the Jenkins master (from ~/.ssh). I have only 1 submodule, and I had no more auth issues. The code expanded correctly and started its compilation phase correctly. Thanks a lot! 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] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Xavier Van Dessel commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated Further to the above, I also tested this combination (same Jenkins and target slave config): git repository accessed via HTTP to the same BitBucket server, using a normal user with password. However, I had first to checkout the .submodules file, then modify the url to convert that one to the HTTP protocol with the same userid as the main fetch will use. When that is done, the fetch of the submodule worked OK. I think it is safe to assume that people will be using a unique way to fetch data (both the main fetch and submodule fetch). 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-31343) Allow to set a max delay on the "Wait for condition"
Title: Message Title
Xavier Van Dessel updated an issue
Jenkins / JENKINS-31343
Allow to set a max delay on the "Wait for condition"
Change By:
Xavier Van Dessel
The waitUntil function calls the WaitForConditionStep class which implements a loop that alternates between a sleep section and the execution of a user specified code section which results in a boolean. In order not to overload the system, the loop time is gradually increased using a muliplication factor of 1.2 (constant RECURRENCE_PERIOD_BACKOFF) ans and a starting delay time of 250 ms (MIN_RECURRENCE_PERIOD). However, there is no upper limit defined. In the code for the WaitForConditionStep, there is even a comment that questions whether a maximum would be useful.In the implementation we want to achieve, such upper limit for the recurrence period is mandatory. The cumulative delays can reach more than one day. A relatively simple calculation shows that after one day the recurrence periode has increased to at least one hour, en could easily reach more than 3 hours. This is practically unacceptable.The recommended solution would then be to have a parameter on the waitUntil call. The suggested name is MaxRecurrencePeriod. If no value is given or if 0 is given, there would be no upper limit on the recurrence period (behaviour as is today). If a value is given, it would be the upper limit of the recurrence period in seconds.Please note that this improvement would also allow for an easy work around for issue JENKINS-30269. With the below code, the functionality requested in that ticket can be obtained. Please note that it circumvents the comment regarding LockableResource being transient by using temporary objects (hence the null assignments). The code is just an example (no testing whether te resource exists etc).{noformat}import org.jenkins.plugins.lockableresources.*;def resName = "testres1"echo "Wait for resource " + resNamewaitUntil {def lrm = LockableResourcesManager.get()def lr = lrm.fromName(resName)def resReserved = lr.isReserved()lrm = nulllr = nullreturn !resReserved}{noformat}Thanks!
Add Comment
[JIRA] [workflow-plugin] (JENKINS-31343) Allow to set a max delay on the "Wait for condition"
Title: Message Title Xavier Van Dessel created an issue Jenkins / JENKINS-31343 Allow to set a max delay on the "Wait for condition" Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 02/Nov/15 1:46 PM Priority: Minor Reporter: Xavier Van Dessel The waitUntil function calls the WaitForConditionStep class which implements a loop that alternates between a sleep section and the execution of a user specified code section which results in a boolean. In order not to overload the system, the loop time is gradually increased using a muliplication factor of 1.2 (constant RECURRENCE_PERIOD_BACKOFF) ans a starting delay time of 250 ms (MIN_RECURRENCE_PERIOD). However, there is no upper limit defined. In the code for the WaitForConditionStep, there is even a comment that questions whether a maximum would be useful. In the implementation we want to achieve, such upper limit for the recurrence period is mandatory. The cumulative delays can reach more than one day. A relatively simple calculation shows that after one day the recurrence periode has increased to at least one hour, en could easily reach more than 3 hours. This is practically unacceptable. The recommended solution would then be to have a parameter on the waitUntil call. The suggested name is MaxRecurrencePeriod. If no value is given or if 0 is given, there would be no upper limit on the recurrence period (behaviour as is today). If a value is given, it would be the upper limit of the recurrence period in seconds. Please note that this improvement would also allow for an easy work around for issue
[JIRA] [lockable-resources-plugin] (JENKINS-30269) Add workflow support for resource locking
Title: Message Title Xavier Van Dessel commented on JENKINS-30269 Re: Add workflow support for resource locking A suggested work around for this problem is documented in ticket JENKINS-31343. However, if the delay on the resource would be rather long (several hours to a day or more) the frequency of the resource check would be so slow that you easily loose an hour before detecting that the resource has been freed. 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-31343) Allow to set a max delay on the "Wait for condition"
Title: Message Title
Xavier Van Dessel updated an issue
Jenkins / JENKINS-31343
Allow to set a max delay on the "Wait for condition"
Change By:
Xavier Van Dessel
The waitUntil function calls the WaitForConditionStep class which implements a loop that alternates between a sleep section and the execution of a user specified code section which results in a boolean. In order not to overload the system, the loop time is gradually increased using a muliplication factor of 1.2 (constant RECURRENCE_PERIOD_BACKOFF) ans a starting delay time of 250 ms (MIN_RECURRENCE_PERIOD). However, there is no upper limit defined. In the code for the WaitForConditionStep, there is even a comment that questions whether a maximum would be useful.In the implementation we want to achieve, such upper limit for the recurrence period is mandatory. The cumulative delays can reach more than one day. A relatively simple calculation shows that after one day the recurrence periode has increased to at least one hour, en could easily reach more than 3 hours. This is practically unacceptable.The recommended solution would then be to have a parameter on the waitUntil call. The suggested name is MaxRecurrencePeriod. If no value is given or if 0 is given, there would be no upper limit on the recurrence period (behaviour as is today). If a value is given, it would be the upper limit of the recurrence period in seconds.Please note that this improvement would also allow for an easy work around for issue JENKINS-30269. With the below code, the functionality requested in that ticket can be obtained. Please note that it circumvents the comment regarding LockableResource being transient by using temporary objects (hence the null assignments). The code is just an example (no testing whether te resource exists etc).{ { noformat} import org.jenkins.plugins.lockableresources.*;def resName = "testres1"echo "Wait for resource " + resNamewaitUntil {def lrm = LockableResourcesManager.get()def lr = lrm.fromName(resName)def resReserved = lr.isReserved()lrm = nulllr = null return !resReserved} {noformat } } Thanks!
Add Comment
[JIRA] [workflow-plugin] (JENKINS-29037) Add Max interval to waitUntil
Title: Message Title Xavier Van Dessel commented on JENKINS-29037 Re: Add Max interval to waitUntil If the average delay amounts to hours or days, as can be the case for resources, the delay becomes huge (hours), which cannot be justified by overhead cost. Hence, a maximum value makes a lot of sense in these cases. 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.
