Daniel Beck added a comment - 2014-08-15 02:16 Does the variable exist when you run env (in a Shell build step) or set (in a Batch build step)?

Damien Nozay added a comment - 2014-08-15 18:04 the var is available in the environment in a shell build step. Started by user damien [EnvInject] - Loading node environment variables. Building on master in workspace /jenkins_data/jenkins/jobs/playground/jobs/test-user/workspace Unrecognized macro 'BUILD_USER_ID' in '#${BUILD_NUMBER} - by ${BUILD_USER_ID}' [workspace] $ /bin/sh -xe /tmp/hudson4283431871309031896.sh + env BUILD_CAUSE_MANUALTRIGGER= true JOB_NAME=playground/test-user BUILD_USER_ID=damien BUILD_DISPLAY_NAME=#2 BUILD_CAUSE=MANUALTRIGGER BUILD_ID=2014-08-15_11-01-01 ... BUILD_USER_FIRST_NAME=damien BUILD_USER=damien Unrecognized macro 'BUILD_USER_ID' in '#${BUILD_NUMBER} - by ${BUILD_USER_ID}' Finished: SUCCESS other issues: job doesn't fail even though macro expansion failed.

Alex Earl added a comment - 2015-10-27 14:01 What version of token macro do you have installed?

Lev Mishin added a comment - 2015-11-06 07:08 - edited It seems you need to use ${ENV, var="BUILD_USER_ID"} so the bug is not related to build-name-setter, please read about Token macro plugin to know how to write macros correctly

Alex Earl added a comment - 2015-11-06 10:00 $BUILD_USER_ID should work since TokenMacro.expandAll is being used. It's possible that the variables aren't available because build-user-vars isn't setting them up correctly. I am not familiar with that plugin.

Lev Mishin added a comment - 2016-04-24 08:51 Damien Nozay please check if the bug still persists and let me know. Also please provide more detailed description (reproduce steps including setting BUILD_USER_ID)

bright.ma added a comment - 2020-04-24 14:51 - edited The BUILD_USER_* variables were init  by plugin "Jenkins user build vars plugin",   this plugin execute after plugin " Build Name and Description Setter". when you configure the plugin "Build Name and Description Setter",  you can choose "Set build name before build starts" or "Set build name after build ends". The two plugin execution sequence maybe like this:  ①"Build Name and Description Setter" if you choose "Set build name before build starts"  -->  ②"Jenkins user build vars plugin" init BUILD_USER_* variables --> ③"Build Name and Description Setter" if you choose "Set build name after build ends".   The order of execution is determined by "Extension ordinal value", but the two plugin set this value is zero. so the order is determined by getDisplayName() value. the displayname one is "Set Build Name"  another is  "Set jenkins user build variables".      the source code is here   /** * Sort {@link ExtensionComponent}s in the descending order of {@link #ordinal()}. */ public int compareTo(ExtensionComponent<T> that) { double a = this .ordinal(); double b = that.ordinal(); if (a>b) return -1; if (a<b) return 1; // make the order bit more deterministic among extensions of the same ordinal if ( this .instance instanceof Descriptor && that.instance instanceof Descriptor) { try { return Util.fixNull(((Descriptor) this .instance).getDisplayName()).compareTo(Util.fixNull(((Descriptor)that.instance).getDisplayName())); } catch (RuntimeException | LinkageError x) { LOG.log(Level.WARNING, null , x); } } return this .instance.getClass().getName().compareTo(that.instance.getClass().getName()); }     Is my analysis correct ???