[JIRA] (JENKINS-32974) Sorting builds is broken with multi-branch builds
Title: Message Title Colin Bennett commented on JENKINS-32974 Re: Sorting builds is broken with multi-branch builds Seems related to JENKINS-37369, if I understand this issue correctly. The problem is that folders or multi-branch container jobs don't propagate the last-build information up to themselves, so there is no way to get an overview at the top level. 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-37369) Multibranch Pipeline: Last build information is not propagated to Jenkins View
Title: Message Title Colin Bennett commented on JENKINS-37369 Re: Multibranch Pipeline: Last build information is not propagated to Jenkins View It is definitely unintuitive to have the last success/last failure value be N/A for multibranch pipeline jobs. One thing that I often do is sort all Jenkins jobs by last failure to see what the recently failing builds are on the server. I'm not sure how I can do this with multibranch pipeline jobs. 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] [git-plugin] (JENKINS-18588) Git polling builds same branch multiple times when 'Execute concurrent builds if necessary' turned on
Title: Message Title Colin Bennett reopened an issue The bug still exists with Git plugin v2.4.4 and Jenkins v1.642.3. I can see why it exists, since if the last built commit is X, and then Y is committed, a build is triggered for commit Y and the last build data in Jenkins is for X. But if polling happens again (in my case due to a GitLab web hook posting to Jenkins) then a second concurrent build will be started for commit Y, since the last completed build was for X. Jenkins / JENKINS-18588 Git polling builds same branch multiple times when 'Execute concurrent builds if necessary' turned on Change By: Colin Bennett Resolution: Cannot Reproduce Status: Resolved 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
[JIRA] [git-plugin] (JENKINS-18588) Git polling builds same branch multiple times when 'Execute concurrent builds if necessary' turned on
Title: Message Title Colin Bennett commented on JENKINS-18588 Re: Git polling builds same branch multiple times when 'Execute concurrent builds if necessary' turned on I confirm the existence of this bug. Apparently since the Git plugin is looking only at the last completed build's Git commit hash, concurrent builds are not identified. The solution is probably to implement something like the Groovy script Jeff Skjonsby posted above, except implement it in the Git plugin directly. If manually triggered, we might actually want to rebuild the same commit twice concurrently (different parameters? want to compare consistency of test runs?) but for polling we would only expect to fire up a single build for a particular commit. 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] [shiningpanda-plugin] (JENKINS-16176) ShiningPanda PATH update uses wrong separator on Windows
Title: Message Title
Colin Bennett commented on JENKINS-16176
Re: ShiningPanda PATH update uses wrong separator on Windows
Here's a possible way to use Python itself for a cross-platform PATH workaround hack. Call this script with the name of the command to run with a corrected PATH:
python -c "import os; import sys; import subprocess; env=os.environ.copy(); badsep = {':': ';', ';': ':'}[os.pathsep]; env['PATH'] = env['PATH'].replace(badsep, os.pathsep); subprocess.call(sys.argv[1:], env=env)" python --version
# Replace "python --version" with any other command to run
This can be run on either Windows cmd.exe or a bash shell on Windows or Linux.
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] [shiningpanda-plugin] (JENKINS-16176) ShiningPanda PATH update uses wrong separator on Windows
Title: Message Title Colin Bennett commented on JENKINS-16176 Re: ShiningPanda PATH update uses wrong separator on Windows Look at this very similar bug JENKINS-14515 , especially this code change that uses toComputer(): 8b09f8bbff45...6f337351a745: -EnvVars vars = new EnvVars(); +EnvVars vars = node.toComputer().getEnvironment(); 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] [shiningpanda-plugin] (JENKINS-16176) ShiningPanda PATH update uses wrong separator on Windows
Title: Message Title Colin Bennett commented on JENKINS-16176 Re: ShiningPanda PATH update uses wrong separator on Windows Weird – I am seeing an incorrect path in the converse way – there are semicolons getting inserted into the Linux slave's PATH. I have a Windows master and Linux slave. The PATH variable is set like this /usr/lib/jvm/java-7-openjdk-amd64/bin:/var/jenkins/workspace/testproject;/var/jenkins/shiningpanda/jobs/ef9d92b6/virtualenvs/4a2c09ff/bin;/var/jenkins/bin:/var/jenkins/bin/cmake-3.5.0-rc2-Linux-x86_64/bin:/usr/local/bin:/usr/bin:/bin 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-32658) Multibranch pipeline 'checkout scm' does not handle Git submodules
Title: Message Title
Colin Bennett updated an issue
Jenkins / JENKINS-32658
Multibranch pipeline 'checkout scm' does not handle Git submodules
Change By:
Colin Bennett
When using a Multibranch Pipeline job type, the Jenkinsfile in the SCM repository branch being built contains the statement {{checkout scm}}. But if the Git repository contains submodules, they are not initialized or updated in the Jenkins build workspace.Typically submodule initialization/updating is automatically handled by the Git SCM for Jenkins Freestyle jobs.h4. WorkaroundYou can call the {{git}} executable manually from the Jenkinsfile pipeline DSL, like this:{noformat}checkout scm execute bat 'git submodule update --init' // or sh {noformat}
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-32658) Multibranch pipeline 'checkout scm' does not handle Git submodules
Title: Message Title Colin Bennett created an issue Jenkins / JENKINS-32658 Multibranch pipeline 'checkout scm' does not handle Git submodules Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 27/Jan/16 6:49 PM Labels: multibranch git git-submodule Priority: Minor Reporter: Colin Bennett When using a Multibranch Pipeline job type, the Jenkinsfile in the SCM repository branch being built contains the statement checkout scm. But if the Git repository contains submodules, they are not initialized or updated in the Jenkins build workspace. Typically submodule initialization/updating is automatically handled by the Git SCM for Jenkins Freestyle jobs. Workaround You can call the git executable manually from the Jenkinsfile pipeline DSL, like this: checkout scm execute 'git submodule update --init'
[JIRA] [workflow-plugin] (JENKINS-32658) Multibranch pipeline 'checkout scm' does not handle Git submodules
Title: Message Title Colin Bennett updated an issue Jenkins / JENKINS-32658 Multibranch pipeline 'checkout scm' does not handle Git submodules Change By: Colin Bennett Issue Type: Bug Improvement 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-30744) multibranch issues if branch contains /
Title: Message Title
Colin Bennett commented on JENKINS-30744
Re: multibranch issues if branch contains /
@gitt I see the same thing.
Running on master in C:\Jenkins\Home\workspace\dgx_mcpu\topic%2Fpipelinetest
[Pipeline] node {
[Pipeline] echo
Posting GitLab commit status: pending
[Pipeline] Enforce time limit : Start
[Pipeline] timeout {
[Pipeline] isUnix
[Pipeline] bat
[topic%2Fpipelinetest] Running batch script
Sending interrupt signal to process
Sending interrupt signal to process
Sending interrupt signal to process
Click here to forcibly terminate running steps
Aborted by Colin D Bennett
Sending interrupt signal to process
Click here to forcibly terminate running steps
Click here to forcibly terminate running steps
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-plugin] (JENKINS-31924) GitSCMSource should offer extensions
Title: Message Title
Colin Bennett commented on JENKINS-31924
Re: GitSCMSource should offer extensions
Workaround
I tried a few ways to get the equivalent of a Git Clean Before Checkout behavior in a Multibranch Pipeline job. Here is what is working for me now: using a manual call to git clean, falling back on deleteDir() pipeline statement if there is no existing Git repository in the workspace:
node {
gitClean()
checkout scm
/* ... rest of the build ... */
}
/**
* Clean a Git project workspace.
* Uses 'git clean' if there is a repository found.
* Uses Pipeline 'deleteDir()' function if no .git directory is found.
*/
def gitClean() {
timeout(time: 60, unit: 'SECONDS') {
if (fileExists('.git')) {
echo 'Found Git repository: using Git to clean the tree.'
// The sequence of reset --hard and clean -fdx first
// in the root and then using submodule foreach
// is based on how the Jenkins Git SCM clean before checkout
// feature works.
bat 'git reset --hard'
// Note: -e is necessary to exclude the temp directory
// .jenkins-X in the workspace where Pipeline puts the
// batch file for the 'bat' command.
bat 'git clean -ffdx -e ".jenkins-*/"'
bat 'git submodule foreach --recursive git reset --hard'
bat 'git submodule foreach --recursive git clean -ffdx'
}
else
{
echo 'No Git repository found: using deleteDir() to wipe clean'
deleteDir()
}
}
}
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
[JIRA] [git-plugin] (JENKINS-31924) GitSCMSource should offer extensions
Title: Message Title
Colin Bennett edited a comment on JENKINS-31924
Re: GitSCMSource should offer extensions
h3. Workaround for "Clean Before Checkout" Equivalent I tried a few ways to get the equivalent of a Git Clean Before Checkout behavior in a Multibranch Pipeline job. Here is what is working for me now: using a manual call to {{git clean}}, falling back on {{deleteDir()}} pipeline statement if there is no existing Git repository in the workspace:{code}node {gitClean()checkout scm/* ... rest of the build ... */}/** * Clean a Git project workspace. * Uses 'git clean' if there is a repository found. * Uses Pipeline 'deleteDir()' function if no .git directory is found. */def gitClean() {timeout(time: 60, unit: 'SECONDS') {if (fileExists('.git')) {echo 'Found Git repository: using Git to clean the tree.'// The sequence of reset --hard and clean -fdx first// in the root and then using submodule foreach// is based on how the Jenkins Git SCM clean before checkout// feature works.bat 'git reset --hard'// Note: -e is necessary to exclude the temp directory// .jenkins-X in the workspace where Pipeline puts the// batch file for the 'bat' command.bat 'git clean -ffdx -e ".jenkins-*/"'bat 'git submodule foreach --recursive git reset --hard'bat 'git submodule foreach --recursive git clean -ffdx'}else{echo 'No Git repository found: using deleteDir() to wipe clean'deleteDir()}}}{code}
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] [xshell-plugin] (JENKINS-26169) Workflow support for XShell plugin
Title: Message Title
Colin Bennett commented on JENKINS-26169
Re: Workflow support for XShell plugin
This would be great. It regrettable that making portable builds is so difficult. Here is a workaround in the meantime:
#!groovy
node {
execute 'cmake -G Ninja ..'
execute 'cmake --build .'
// Run a program that is in the current directory.
executeCwd 'myprogram --test'
}
/**
* Execute a program that exists in the current working directory.
*
* On Unix, the current working directory is not implicitly in the PATH,
* so the command must be prefixed with "./".
*
* On Windows, the current directory is first in the search path, but
* it does not like the "./" used for a Unix-style command.
*
* Therefore we have to do something special in each case.
*/
def executeCwd(commandString) {
if (isUnix()) {
execute("./" + commandString)
} else {
execute(".\\" + commandString)
}
}
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-32540) Multibranch workflow and 'scm checkout' don't allow Git clean before checkout
Title: Message Title Colin Bennett created an issue Jenkins / JENKINS-32540 Multibranch workflow and 'scm checkout' don't allow Git clean before checkout Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 20/Jan/16 5:17 PM Environment: Jenkins v1.625.3 LTS Pipeline plugin v1.13 Priority: Major Reporter: Colin Bennett Need to be able to build in a clean project checkout There seems to be no way to obtain a clean workspace using the multibranch pipeline job with the checkout scm statement. With the old workflow job type (not multibranch), it was not directly supported by the pipeline DSL, but it was possible to manually configure the Git SCM plugin with the CleanBeforeCheckout extension like this: checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'your_url_here']], extensions: [[$class: 'CleanBeforeCheckout']]]) It does not seem possible to obtain this behavior while using the checkout scm shortcut in the multibranch pipeline job's Jenkinsfile.
[JIRA] [git-client-plugin] (JENKINS-21248) Add shallow update init for submodule
Title: Message Title Colin Bennett commented on JENKINS-21248 Re: Add shallow update init for submodule +1 I would like to see this implemented. That pull request may not be perfect in terms of design purity but it is better than not having the feature. 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] [analysis-core] (JENKINS-10596) Improve handling of source code files with duplicate relative path names
Colin Bennett commented on JENKINS-10596 Improve handling of source code files with duplicate relative path names What is the "scan workspace option"? I see there is a "Scan workspace files" section with an "Add" button that allows one to "Workspace files to scan for compiler warnings using a predefined parser", but that's not what I want, I am already scanning and correctly capturing the warnings on the console output I don't have a log file to scan. I did try to enable the "Resolve relative paths" checkbox under "Advanced..." but that didn't fix the issue. I am using a custom parser for the Freescale (formerly Metrowerks) ColdFire compiler, with the "-msgstyle gcc" option. Here's the regex: ^\s*(?:\[exec\])\s*(.*):(\d+):\s*(warning|error): (\S.*)$ and here's the mapping script: import hudson.plugins.warnings.parser.Warning String fileName = matcher.group(1) String lineNumber = matcher.group(2) String category = matcher.group(3) String message = matcher.group(4) return new Warning(fileName, Integer.parseInt(lineNumber), "Dynamic Parser", category, message); and here's an example message: [exec] ..\..\..\..\common\comps\mx\mqx\mxDefs.h:247: warning: florbity frobbity grokkity goo I see no problem with the parsing; it works fine and correctly identifies the file path and line number etc. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [analysis-core] (JENKINS-10596) Improve handling of source code files with duplicate relative path names
Colin Bennett edited a comment on JENKINS-10596 Improve handling of source code files with duplicate relative path names I have encountered this issue again. Jenkins ver. 1.539 Warnings plugin 4.38 Content of file C_IcspAutoIPTransport.c 01 Copying the source file '../../../../common/comps/C_Icsp/common/C_IcspAutoIPTransport.c' from the workspace to the build folder 'C:\Jenkins\Home\jobs\Corvette_RX_Integration\builds\2013-12-10_16-19-48\workspace-files\2c97d6fe.tmp' on the Jenkins master failed. 02 Seems that the path is relative, however an absolute path is required when copying the sources. 03 Is the file 'C_IcspAutoIPTransport.c' contained more than once in your workspace? 04 Is the file '../../../../common/comps/C_Icsp/common/C_IcspAutoIPTransport.c' a valid filename? 05 If you are building on a slave: please check if the file is accessible under '$JENKINS_HOME/[job-name]/../../../../common/comps/C_Icsp/common/C_IcspAutoIPTransport.c' 06 If you are building on the master: please check if the file is accessible under '$JENKINS_HOME/[job-name]/workspace/../../../../common/comps/C_Icsp/common/C_IcspAutoIPTransport.c' 07 java.io.FileNotFoundException: ..\..\..\..\common\comps\C_Icsp\common\C_IcspAutoIPTransport.c (The system cannot find the path specified) 08 at java.io.FileInputStream.open(Native Method) 09 at java.io.FileInputStream.init(Unknown Source) 10 at hudson.FilePath$34.invoke(FilePath.java:1778) 11 at hudson.FilePath$34.invoke(FilePath.java:1773) 12 at hudson.FilePath.act(FilePath.java:917) 13 at hudson.FilePath.act(FilePath.java:890) 14 at hudson.FilePath.copyTo(FilePath.java:1773) 15 at hudson.plugins.analysis.core.HealthAwareRecorder.copyFilesWithAnnotationsToBuildFolder(HealthAwareRecorder.java:398) 16 at hudson.plugins.warnings.WarningsPublisher.perform(WarningsPublisher.java:334) 17 at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:333) 18 at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:32) 19 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:781) 20 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:753) 21 at hudson.model.Build$BuildExecution.post2(Build.java:183) 22 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:706) 23 at hudson.model.Run.execute(Run.java:1704) 24 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 25 at hudson.model.ResourceController.execute(ResourceController.java:88) 26 at hudson.model.Executor.run(Executor.java:230) I get this error for all the source files because they are all referenced using ../../../foo/bar/baz.c type relative paths. For instance, the file in the above error trace is actually located: $ git ls-files */C_IcspAutoIPTransport.c products/hardware/common/comps/C_Icsp/common/C_IcspAutoIPTransport.c The make process driving the build was being performed with a current working directory of something like x/y/z/projname/build, basically all the ../../../.. just are a relative way of referring to the Git project tree root. (In particular, because Cygwin GNU make does not like C:\foo absolute paths it chokes on the : colon and so I have to use tedious relative paths to avoid this.) Also, note that there's only one file with this "basename" so there is not ambiguity. We could maybe have a simple fallback case if the usual absolute resolution fails that could search for the file by basename only, if it's not ambiguous. The problem with completely fixing this issue is that it's hard for Jenkins to know universally what the current directory was when that warning was emitted, so it doesn't know that ../../../../.. refers to project root. But at least a workaround that would use a search for basename when not ambiguous would be a 90% solution. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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
[JIRA] [analysis-core] (JENKINS-10596) Improve handling of source code files with duplicate relative path names
Colin Bennett commented on JENKINS-10596 Improve handling of source code files with duplicate relative path names What is that "new gcc parser with make support"? I am BTW using a Freescale/Metrowerks ColdFire compiler... ugh... much prefer gcc of course. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
