${GIT_REVISION,length=8}Hi future me.
If you're not me, you probably already have the GitHub Plugin installed, which pulls in the base Git Plugin. And if you started reading on the wiki page for the git plugin you may have noticed a reference to a environment variable available as GIT_COMMIT. After some bit of searching you bump into the Build Name Setter Plugin, and try adding some stuff in the "Build Name" field on the job configuration maybe like:
${GIT_COMMIT}-${BUILD_NUMBER}Which doesn't work, so you go back to more important stuff.
Or maybe you get lucky and realize the Token Macro Plugin is involved and stumble across the example there. Which is hidden in-between some Java you can barely look at, is the small blurb at the end of a paragraph which mentions "${GIT_REVISION,length=8}".
What was interesting there for me was that the build name setter relies completely on the token macro plugin for the string expansion, and pulling strings out of the ENV is not it's primary purpose. There's a special syntax even:
${ENV,var="GIT_COMMIT"}Which if you discovered, probably frustrated you, since can't seem to use the ENV vars you export during the build script, or even do basic bash variable manipulation like ${GIT_COMMIT:0:8}.
At this point you're realizing the fact that the token macro expansion only looks like bash variable expansion to confuse you.
Jenkins plugins can and do internally in their java guts define and export sometimes parameterized "tokens" which are exported for the specific purpose of being available to the token macro plugin which the build name setter users.
I honestly had no idea how anyone was supposed to know how this stuff worked together short of trolling through the git plugin's source like I did and reading GitRevisionTokenMacro. But when I looked at the commit, my eyes were opened!
So my new plan is to "always click the ? first" - why wasn't that my old plan?