Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
Description
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 ${BUILD_URL}
- ${CAUSE_PROJECT_NAME}: equivalent of ${PROJECT_NAME}
- ${CAUSE_BUILD_NUMBER}: equivalent of ${BUILD_NUMBER}
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Summary | Support ${CAUSE_URL} also in addition to ${CAUSE} | Support ${CAUSE_BUILD_URL} also in addition to ${CAUSE} |
| Component/s | token-macro-plugin [ 15832 ] | |
| Assignee | David van Laatum [ davidvanlaatum ] | Alex Earl [ slide_o_mix ] |
| Description |
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}}} |
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 {{$\{BUILD_URL}}} * {{$\{CAUSE_PROJECT_NAME}}}: equivalent of {{$\{PROJECT_NAME}}} * {{$\{CAUSE_BUILD_NUMBER}}}: equivalent of {{$\{BUILD_NUMBER}}} |
The Cause object itself doesn't give anything but the getShortDescription. I can get the upstream job by checking if the Cause is an UpstreamCause, but some macros require a workspace which I would not have access to. It could cause issues for people trying to use some macros with the upstream job.
Not sure I follow here. How is the workspace related to this? In my "black box" view all it takes is getting a link to the job that triggered it - if there is one. If there is no job, then this would not work and the macro is empty. Or well, ir could give the user name,so
- "BUILD_URL" should be just "URL" would link to the jenkins user's page.
- "PROJECT_NAME" is the user's name as string
- "BUILD_NUMBER" is empty.
I wonder, how many "causes" are there besides "job" and "user"?
In order to make it scalable, I would want to call the macro expansion with the upstream run as the run for the expansion. Some macros require a workspace. This would be a problem
Code changed in jenkins
User: Alex Earl
Path:
src/main/java/org/jenkinsci/plugins/tokenmacro/impl/BuildCauseMacro.java
src/test/java/org/jenkinsci/plugins/tokenmacro/impl/BuildCauseMacroTest.java
http://jenkins-ci.org/commit/token-macro-plugin/4d24aa5716f8d84e236824ab36d87c90a9897e8d
Log:
Fix JENKINS-42699
- Add data parameter which can accept BUILD_URL, PROJECT_NAME, or BUILD_NUMBER
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
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: