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="BUILD_URL"}
• ${CAUSE,data="PROJECT_NAME"}
• ${CAUSE,data="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

Fixed in 2.4 (released soon)

Thanks!