[JIRA] (JENKINS-26100) SCM steps should return revision state
Title: Message Title Yury Zaytsev commented on JENKINS-26100 Re: SCM steps should return revision state aleksey savitskiy my repository is ~2G large and I have lots of small files in it. Very unfortunately, stash is simply not usable for anything beyond a couple of dozens of megabytes and hundreds of files. 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-26100) SCM steps should return revision state
Title: Message Title Yury Zaytsev commented on JENKINS-26100 Re: SCM steps should return revision state Just to clarify what you see on the screenshot: first it started building revision 3dc9d2b (1 commits since the last build), but then someone merged another branch while the pipeline was running, and checkout scm in the later stages picked up the new state 0825e24 (4 commits more), which is two merge commits away from the last build. Now, in the meantime, build #83 has been triggered with 0825e24, and both kept running in parallel, which, of course, doesn't make any sense. Ideally, I would like newer builds to abort previous ones as they get to the end of the stage, but, in the mean time, at least checkout scm should always checkout the same thing within one build. So, thank you for answering, but I can't see how what you're saying is correct. 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-26100) SCM steps should return revision state
Title: Message Title Yury Zaytsev updated an issue Jenkins / JENKINS-26100 SCM steps should return revision state Change By: Yury Zaytsev Attachment: multibranch-wrong-revision.png 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-26100) SCM steps should return revision state
Title: Message Title Yury Zaytsev commented on JENKINS-26100 Re: SCM steps should return revision state > If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm. I'm very surprised to hear that. Multibranch pipeline project is exactly what I have. In my pipeline, I have multiple stages, which all do checkout scm for now, and inside each stage I have checkouts on multiple workers in parallel. The pipeline currently runs for an hour, or so, and if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started. I want checkout scm to always checkout the commit which triggered the build, and not the branch which triggered the build, whatever the branch state is. Please see a screenshot attached... 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-26100) SCM steps should return revision state
Title: Message Title Yury Zaytsev commented on JENKINS-26100 Re: SCM steps should return revision state I understand that this is still not implemented, therefore one needs to go the rev-parse way, but is there a possibility to modify scm object to use the correct revision, instead of making a brand new one, like checkout([$class: 'GitSCM', branches: [[name: 'XXX']], extensions: [[$class: 'SubmoduleOption', parentCredentials: true], [$class: 'CleanCheckout']], userRemoteConfigs: [[credentialsId: 'YYY', url: 'ZZZ']]]) and basically have to duplicate all the SCM settings? Sorry for a newb Groovy question, if this is trivial. 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-34564) Give the ability to choose how the multibranch subprojects will be named.
Title: Message Title Yury Zaytsev commented on JENKINS-34564 Re: Give the ability to choose how the multibranch subprojects will be named. > which sounds like a bug in Python: it should use /usr/bin/env. Just for the record: this isn't a bug by any means. They do it on purpose, because installed modules should be bound to a specific installing interpreter for many reasons. The question is, can they apply some hacks on their side to work around limited shebang path length issue or not, but it's a tangential one, and, in any case, the latest status was that if one could think of something, they'd welcome patches. 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-34564) Give the ability to choose how the multibranch subprojects will be named.
Title: Message Title Yury Zaytsev reopened an issue So, in addition to causing massive problems on Windows, this also causes trouble on Unix, if the workspace contains shell scripts which use binaries residing in the workspace as interpreters. That is, something like what follows: $ cat foo #!/home/jenkins/agent/workspace/xxx-O7T6IFSVMNBO5RYGRVNFUGEOPAZAIQ4GQRK47UUDIOZMEN3K2OAA/source/lib/python-san/install/bin/python-dbg One might think this ought to happen very rarely, but that's not the case! Basically, when you install any Python modules in a local prefix tree, it hardcodes the absolute path to the interpreter into the scripts and are you are screwed See here for the details on `#!` maximum length limits (127 bytes on Linux): http://www.in-ulm.de/~mascheck/various/shebang/ Jenkins / JENKINS-34564 Give the ability to choose how the multibranch subprojects will be named. Change By: Yury Zaytsev Resolution: Fixed Status: Resolved Reopened Add Comment
[JIRA] (JENKINS-2111) removing a job (including multibranch/org folder branches/repos) does not remove the workspace
Title: Message Title Yury Zaytsev commented on JENKINS-2111 Re: removing a job (including multibranch/org folder branches/repos) does not remove the workspace So was it addressed in JENKINS-34564 ? I've had a look at the commit mentioned in Jira, but I couldn't easily see any code pertaining to the deletion of the workspaces. 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-34564) Give the ability to choose how the multibranch subprojects will be named.
Title: Message Title Yury Zaytsev commented on JENKINS-34564 Re: Give the ability to choose how the multibranch subprojects will be named. It seems that fixing this issue can't be too easy apparently the default 80-char limit was way too generous for Windows slaves. But does it really warrant decreasing it? Or rather advice users to not to bury workspace too deep in the hierarchy? Ben Herfurth, in light of all problems with Windows path length limitations, why wouldn't you just give Jenkins agent a reasonable workspace path, e.g. C:\Jenkins\workspace <--- this should work. 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-34564) Give the ability to choose how the multibranch subprojects will be named.
Title: Message Title Yury Zaytsev commented on JENKINS-34564 Re: Give the ability to choose how the multibranch subprojects will be named. Awesome, thank you very much! Could you please tell in which plugin / release it will become available? Many thanks! 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-34564) Give the ability to choose how the multibranch subprojects will be named.
Title: Message Title
Yury Zaytsev commented on JENKINS-34564
Re: Give the ability to choose how the multibranch subprojects will be named.
For the benefit of other affected users, I'm posting a workaround suggested by @rrodriguez__ on #jenkins IRC based on the comment in a linked ticket ( https://issues.jenkins-ci.org/browse/JENKINS-30744?focusedCommentId=247893#comment-247893 ):
node(agent) {
def workspace_orig = pwd()
def workspace_sane = workspace_orig.replaceAll("%", "_")
ws(workspace_sane) {
// ...
}
}
I've also filed a bug report against Boost: https://svn.boost.org/trac/boost/ticket/12448 , but I'm not sure if one should really expect them to fix this anytime soon.
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-34564) Give the ability to choose how the multibranch subprojects will be named.
Title: Message Title Yury Zaytsev commented on JENKINS-34564 Re: Give the ability to choose how the multibranch subprojects will be named. Well, I appreciate the desire to treat the problem in depth, but given the nature of the issue, I'd think it warrants a quick workaround first, such that a better solution can be developed without so much pressure. I think the obvious workaround is to use "" instead of "%" in escapes and screen "" with another "_"; this is as close to the current scheme as possible and will keep the bi-directionality of the mapping. (Actually, I personally would have used a modified PunyCode scheme in the first place, but ...). Most build systems don't have problems with underscores, the changes required are minimal and one can then take time to think of and properly implement a better scheme. Currently, multibranch subprojects do not work with the following build systems: Make (it interprets % in rule targets as a wildcard, and no escaping that I've tried seems to work) Boost Jam (fails with obscure error messages, have not identified the underlying problem yet) CMake (as reported in related bugs) MSBuild (as reported in related bugs) Apparently, a number of other build systems / application containers, etc. Large number of plugins (cppcheck, cifs, ...) Of course, one could rightfully argue that all this software is broken, but I hope that some practical solution can be found quickly. This issue is absolutely critical to the usability of the multibranch stuff. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36492) 2.7.1 update check shows weekly version instead of LTS
Title: Message Title Yury Zaytsev commented on JENKINS-36492 Re: 2.7.1 update check shows weekly version instead of LTS Confirmed here. 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-20941) Stored git credentials not used when submodule is updated
Title: Message Title Yury Zaytsev commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated Mark Waite, I've just upgraded to 3.0.0-beta2 and "Additional Behaviors" are back for the multibranch pipeline jobs, also the "Use credentials from default remote of parent repository" checkbox is there and I can confirm that it seems to be working fine for me now! Many thanks and keep up the excellent work 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-20941) Stored git credentials not used when submodule is updated
Title: Message Title
Yury Zaytsev edited a comment on JENKINS-20941
Re: Stored git credentials not used when submodule is updated
FYI, very sadly, the ability to select advanced git behaviors in multibranch pipeline projects is gone again after upgrade from 2.5.2 to 3.0.0-beta1 of the git plugin. I was assuming 3.0.0-beta1 is necessary to go with 2.0.0-beta1 of the git client plugin. After I downgraded to git plugin 2.5.2 again, but left git client 2.0.0-beta1 in, submodule (public key) authentication on the agents still doesn't seem to work even though the main repository is checked out just fine :({noformat}> git submodule update --init --recursive XXXhudson.plugins.git.GitException: Command "git submodule update --init --recursive XXX" returned status code 128:stdout: stderr: Cloning into 'XXX'...Permission denied, please try again.Permission denied, please try again.Permission denied (publickey,password).fatal: Could not read from remote repository.{noformat} P.S. I was not able to find "Use credentials from default remote of parent repository" under "Additional Behaviours", maybe for that git plugin 3.0.0-beta1 is needed, but see above: if I install it, then "Additional Behaviours" vanish from the multibranch pipeline job scm settings.
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-20941) Stored git credentials not used when submodule is updated
Title: Message Title Yury Zaytsev commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated FYI, very sadly, the ability to select advanced git behaviors in multibranch pipeline projects is gone again after upgrade from 2.5.2 to 3.0.0-beta1 of the git plugin. I was assuming 3.0.0-beta1 is necessary to go with 2.0.0-beta1 of the git client plugin. After I downgraded to git plugin 2.5.2 again, but left git client 2.0.0-beta1 in, submodule (public key) authentication on the agents still doesn't seem to work even though the main repository is checked out just fine > git submodule update --init --recursive XXX hudson.plugins.git.GitException: Command "git submodule update --init --recursive XXX" returned status code 128: stdout: stderr: Cloning into 'XXX'... Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password). fatal: Could not read from remote repository. 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.
