[JIRA] (JENKINS-42699) Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Title: Message Title
Axel Heider updated an issue
Jenkins / JENKINS-42699
Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Change By:
Axel Heider
Currently there is {{$\{CAUSE}}} that prints the upstream job that triggered this build. It would be nice to have a the details of the cause available in tokens also, especially the URL. Then the mail can contain a clickable link, which is quite convenient in some case then a build pipeline exists, where one want to get to the "main" job directly.Having these token available would be really nice: * {{$\{CAUSE_BUILD_URL}}}: equivalent of {{$\{ CAUSE_BUILD_URL BUILD_URL }}} * {{$\{CAUSE_PROJECT_NAME}}}: equivalent of {{$\{PROJECT_NAME}}} * {{$\{CAUSE_BUILD_NUMBER}}}: equivalent of {{$\{BUILD_NUMBER}}}
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
[JIRA] (JENKINS-42699) Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Title: Message Title
Axel Heider edited a comment on JENKINS-42699
Re: Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Not sure what's the preferred way to handle this. Besides creating more variables, using the token-parameters approach might also work and scale nicer: * {{$\{CAUSE,data=""diffremovedchars" style="background-color:#ffe7e7;text-decoration:line-through;">url BUILD_URL "}}} * {{$\{CAUSE,data=""diffremovedchars" style="background-color:#ffe7e7;text-decoration:line-through;">NAME PROJECT_NAME "}}} * {{$\{CAUSE,data=""diffremovedchars" style="background-color:#ffe7e7;text-decoration:line-through;">NUMBER BUILD_NUMBER "}}}
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-42699) Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Title: Message Title
Axel Heider commented on JENKINS-42699
Re: Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Not sure what's the preferred way to handle this. Besides creating more variables, using the token-parameters approach might also work and scale nicer:
${CAUSE,data=""}
${CAUSE,data=""}
${CAUSE,data=""}
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-42698) Support default value for parameters if they are not set
Title: Message Title
Axel Heider updated an issue
Jenkins / JENKINS-42698
Support default value for parameters if they are not set
Change By:
Axel Heider
Please consider supporting a default value for parameters if they are empty or unset. There are cases where env parameters {{$\{ENV, var="SOME_ENV_VAR"}}} are not set. And for build parameters there can be the case when it is not set at all. For example, this happens with Groovy scripts that trigger builds, see e.g. JENKINS-13768In these cases it would be nice to be able to print something instead of the empty string. For env vars this seems easy, as it's just another parameters then: {{$\{ENV, var="SOME_ENV_VAR", ifUnset="[ no not set]"}"}}. For build parameters it might be more tricky, but the the same concept might apply. And since they end up in env variables anyway, one workaround would be simply using {{$\{ENV, var="MyBuildParameter", ifUnset="[ no not set]"}}}.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You
[JIRA] (JENKINS-42698) Support default value for parameters if they are not set
Title: Message Title
Axel Heider updated an issue
Jenkins / JENKINS-42698
Support default value for parameters if they are not set
Change By:
Axel Heider
Please consider supporting a default value for parameters if they are empty or unset. There are cases where env parameters {{$\{ENV, var="SOME_ENV_VAR"}}} are no not set. And for build parameters there can be the case when it is not set at all. For example, this happens with Groovy scripts that trigger builds, see e.g. JENKINS-13768In these cases it would be nice to be able to print something instead of the empty string. For env vars this seems easy, as it's just another parameters then: {{$\{ENV, var="SOME_ENV_VAR", ifUnset="[no set]"}"}}. For build parameters it might be more tricky, but the the same concept might apply. And since they end up in env variables anyway, one workaround would be simply using {{$\{ENV, var="MyBuildParameter", ifUnset="[no set]"}}}.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received
[JIRA] (JENKINS-42698) Support default value for parameters if they are not set
Title: Message Title
Axel Heider updated an issue
Jenkins / JENKINS-42698
Support default value for parameters if they are not set
Change By:
Axel Heider
Please consider supporting a default value for parameters if they are empty or unset. There are cases where env parameters {{$\{ENV, var="SOME_ENV_VAR"} " }} are no set. And for build parameters there can be the case when it is not set at all. For exmaple example , this happens with Groovy scripts tthat that trigger builds, see e.g. JENKINS-13768In these cases it would be nice to be able to print something instead of the empty string. For env vars this seems easy, as it's just another parameters then: {{$\{ENV, var="SOME_ENV_VAR", ifUnset="[no set]"}"}}. For build parameters it might be more tricky, but the the same concept might apply. And since they end up in env variables anyway, one workaround would be simply using {{$\{ENV, var="MyBuildParameter", ifUnset="[no set]"}}}.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-42699) Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Title: Message Title
Axel Heider updated an issue
Jenkins / JENKINS-42699
Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE}
Change By:
Axel Heider
Summary:
Support ${ CAUSE_URL CAUSE_BUILD_URL } also in addition to ${CAUSE}
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-42699) Support ${CAUSE_URL} also in addition to ${CAUSE}
Title: Message Title
Axel Heider created an issue
Jenkins / JENKINS-42699
Support ${CAUSE_URL} also in addition to ${CAUSE}
Issue Type:
Improvement
Assignee:
David van Laatum
Components:
email-ext-plugin
Created:
2017/Mar/12 5:01 PM
Labels:
trigger case pipeline parameter
Priority:
Minor
Reporter:
Axel Heider
Currently there is ${CAUSE} that prints the upstream job that triggered this build. It would be nice to have a the details of the cause available in tokens also, especially the URL. Then the mail can contain a clickable link, which is quite convenient in some case then a build pipeline exists, where one want to get to the "main" job directly. Having these token available would be really nice:
${CAUSE_BUILD_URL}: equivalent of ${CAUSE_BUILD_URL}
${CAUSE_PROJECT_NAME}: equivalent of ${PROJECT_NAME}
${CAUSE_BUILD_NUMBER}: equivalent of ${BUILD_NUMBER}
[JIRA] (JENKINS-42698) Support default value for parameters if they are not set
Title: Message Title
Axel Heider created an issue
Jenkins / JENKINS-42698
Support default value for parameters if they are not set
Issue Type:
Improvement
Assignee:
David van Laatum
Components:
email-ext-plugin
Created:
2017/Mar/12 4:53 PM
Labels:
default value parameter
Priority:
Minor
Reporter:
Axel Heider
Please consider supporting a default value for parameters if they are empty or unset. There are cases where env parameters {{${ENV, var="SOME_ENV_VAR"}"}}are no set. And for build parameters there can be the case when it is not set at all. For exmaple, this happens with Groovy scripts tthat trigger builds, see e.g. JENKINS-13768 In these cases it would be nice to be able to print something instead of the empty string. For env vars this seems easy, as it's just another parameters then: ${ENV, var="SOME_ENV_VAR", ifUnset="[no set]"}". For build parameters it might be more tricky, but the the same concept might apply. And since they end up in env variables anyway, one workaround would be simply using ${ENV, var="MyBuildParameter", ifUnset="[no set]"}.
[JIRA] (JENKINS-41707) Support giving folder where patch is applied
Title: Message Title Axel Heider updated an issue Jenkins / JENKINS-41707 Support giving folder where patch is applied Change By: Axel Heider We are putting several different repos into different folders when runnig build job runs. This prevents any folder or file name conflicts. It would be nice if the patch parameter support supports a base-folder where the patch is applied. Then there can Currently this is hard coded to the root folder. This would then also be allow having multiple patch parameters , a specific one for each repo or component we are pulling into the different repos build . 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-41707) Support giving folder where patch is applied
Title: Message Title Axel Heider updated an issue Jenkins / JENKINS-41707 Support giving folder where patch is applied Change By: Axel Heider Priority: Minor Major 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-41707) Support giving folder where patch is applied
Title: Message Title Axel Heider updated an issue Jenkins / JENKINS-41707 Support giving folder where patch is applied Change By: Axel Heider We are putting out several different repos into different folder folders when a runnig build job runs. This prevent prevents any folder or file name conflicts. It would be nice if the patch parameter support a base-folder where the patch is applied. Then there can also be multiple patch parameters for the different repos. 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-41707) Support giving folder where patch is applied
Title: Message Title Axel Heider created an issue Jenkins / JENKINS-41707 Support giving folder where patch is applied Issue Type: Improvement Assignee: Unassigned Components: patch-parameter-plugin Created: 2017/Feb/03 2:29 PM Priority: Minor Reporter: Axel Heider We are putting out several different repos into different folder when a build job runs. This prevent any folder or file name conflicts. It would be nice if the patch parameter support a base-folder where the patch is applied. Then there can also be multiple patch parameters for the different repos. Add Comment
[JIRA] (JENKINS-38121) Patch file processing does not support UTF-8 encoding
Title: Message Title Axel Heider created an issue Jenkins / JENKINS-38121 Patch file processing does not support UTF-8 encoding Issue Type: Bug Assignee: Unassigned Components: patch-parameter-plugin Created: 2016/Sep/12 1:50 AM Environment: * Jenkins 1.598 * patch-parameter plugin V1.2 * diff4j-1.2 from https://github.com/cloudbees/diff4j (7f212fe6f891e8eaaa349ed9fc6866c9d1280dd2) * GNU patch 2.7.5 * SVN 1.9 Labels: encoding java Priority: Critical Reporter: Axel Heider I'm having problem with a patch file that changes a code comment using "’" (RIGHT SINGLE QUOTATION MARK, UTF-8 U+2019 encoded as 0xE2 0x80 0x99) into the (normal?) apostrophe "'" (APOSTROPHE, ASCII 39/0x27). The patch is created with SVN diff (V1.9) in Linux and can be used fine with GNU patch 2.7.5. However, when uploading the patch to jenkins, it can't be applies- The error is com.cloudbees.diff.PatchException: Cannot apply hunk @@ 245 I've debugged the issue using diff4j-1.2 (7f212fe6f891e8eaaa349ed9fc6866c9d1280dd2) from https://github.com/cloudbees/diff4j in a test java application. Adding some printouts in
[JIRA] [groovy-plugin] (JENKINS-34974) Pass shell object to groovy script
Title: Message Title Axel Heider created an issue Jenkins / JENKINS-34974 Pass shell object to groovy script Issue Type: Improvement Assignee: vjuranek Components: groovy-plugin Created: 2016/May/20 9:09 AM Priority: Trivial Reporter: Axel Heider Pass the current "shell" object in the binding to the grovvy script. That would simplify loading and running other groovy scripts from the workspace. Currently I'm using static loadScriptFromWorkspace(build, fileName, loader=null) def scriptFile = build.project.getWorkspace().child(fileName) def cl = loader ?: Jenkins.getInstance().getPluginManager().uberClassLoader def groovyShell = new GroovyShell(cl) return groovyShell.parse(scriptFile.read().newReader()) } And this is invoked with loadScriptFromWorkspace(build, "foo.groovy", this.class.classLoader) With a "shell" object, I can skip the classloader part. static loadScriptFromWorkspace(groovyShell, fileName)
[JIRA] [patch-parameter-plugin] (JENKINS-28984) "patch.diff" is a bad name as env variable due to the dot
Title: Message Title Axel Heider commented on JENKINS-28984 Re: "patch.diff" is a bad name as env variable due to the dot work-around in a shell script is using: printenv patch.diff. That should solve the practical problem. But the name patch.diff is still not the best choice. I understand that is cannot be dropped for compatibility reasons, but another env var name like "patch_file" could be introduced in addition. 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] [groovy-plugin] (JENKINS-31920) System groovy, Variables Binding & Classpath properties don't evaluate jenkions variables
Title: Message Title
Axel Heider edited a comment on JENKINS-31920
Re: System groovy, Variables Binding & Classpath properties don't evaluate jenkions variables
If a build runs, the current dir is always the workspace. Why do you use the {{$WORKSPACE}} variable then instead of just a relative path that is passed to {{build.project.getWorkspace().child("myFile.txt")}} in you your script?Not sure about the classpath, maybe you really need {{$WORKSPACE}} there to reference things from our workspace. Then this feature would make sense here
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] [groovy-plugin] (JENKINS-31920) System groovy, Variables Binding & Classpath properties don't evaluate jenkions variables
Title: Message Title
Axel Heider commented on JENKINS-31920
Re: System groovy, Variables Binding & Classpath properties don't evaluate jenkions variables
If a build runs, the current dir is always the workspace. Why do you use the $WORKSPACE variable then instead of just a relative path that is passed to build.project.getWorkspace().child("myFile.txt") in you script?
Not sure about the classpath, maybe you really need $WORKSPACE there to reference things from our workspace. Then this feature would make sense here
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] [groovy-plugin] (JENKINS-34970) Display advanced details in job config for a groovy script if data is in there by default
Title: Message Title Axel Heider created an issue Jenkins / JENKINS-34970 Display advanced details in job config for a groovy script if data is in there by default Issue Type: Improvement Assignee: vjuranek Components: groovy-plugin Created: 2016/May/20 8:34 AM Environment: Groovy Plugin V1.24 Priority: Major Reporter: Axel Heider Display advanced details in the job config for a groovy script if data is in there. Currently this is not displayed by default, which is a bit inconvenient. We have certain config parameters there and these are easily forgotten if they are not visible. Another solution could be making "Variable bindings" not an advanced parameters if the option "Groovy script file" is selected. This is the way to pass parameters to the script.
