I am using the Google Play Android Publisher Plugin, and trying to send the release notes for a language to the google play store. Currently they are in a file passed down from the previous build job and I am trying to set a environment variable from that using the following command in a execute shell build step.
export LANG_EN_GB=`cat android-*-en-GB`
I am then passing it into the recent changes field using ${LANG_EN_GB} but getting unrecognised macro.
Unrecognized macro 'LANG_EN_GB' in '${LANG_EN_GB}
I have searched online and have tried adding this command but it doesn't work
${ENV,var="LANG_EN_GB"}
I have also seen I can add the EnvInject Plugin but I am not keen to do that for such a small task. Is this the only solution or am I doing something wrong in the execute shell script?
I fixed this by using referring to the File rather than a environment variable.
${FILE, path="android-en-GB"}
It seems the plugin,only works with environment variables set by Jenkins not by script
Related
According to this very old question you can use Bamboo variables in a batch script like %bamboo_buildNumber%, but it doesn't work for me, I just get an empty string. I also tried %bamboo.buildNumber% with the same result. The script is not in-line and is used by a Dockerfile. Does that have an influence on this? Or did something change since the above question was asked?
In the script I have a line
innosetup-compiler MySetup.iss "--DVERSION=%major%.%minor%" "--DPATCH=%bamboo_buildNumber%"
And in my Dockerfile I write
RUN ./MyScript.bat
Update:
So I think whats happening is that because the batch-script is run from the Dockerfile it is also run inside a container and doesn't have access to the Bamboo environment variables because of this. I tried passing the variable in question through the Dockerfile into the script, but it hasn't worked as of yet.
I believe that this has changed in newer versions of Bamboo. The preferred syntax now is to use ${bamboo.buildNumber} when passing variables to a build script. I even use that approach in my old /bin/sh cmd.exe scripts. You'll know you've got it working when you see the following in the logs: Substituting variable: ${bamboo.buildNumber} with xxxx
Once you verify that the above variable substitution is working, you can then troubleshoot how that variable is getting (or not getting) into your Docker scripts.
For more information on the major minor build numbers check out this page. You may need to call it slightly differently if it is a custom variable.
if we are using the script body in bamboo script task then ${bamboo.buildNumber} will work without any issue but if we need to access in bat file or a ps1 file then it is required to access in the below syntax
%bamboo_buildNumber% In a .bat file use
$Env:bamboo_buildNumber in a Powershell file
My machine just had its hard drive re-imaged so I'm trying to rebuild it. At this point, I am trying to execute an ant script which has worked for years. Not anymore. When the script compiles the javac errors because it can't find a directory.
The error is...
BUILD FAILED
C:\Users\WHeckle\Documents\temp\6.9.2\build-tceq.xml:92: C:\Users\WHeckle\Documents\temp\6.9.2\${env.SEAM_HOME}\lib does not exist.
It looks like it is concatenating the current directory with seam_home and using it as a library reference to the compiler.
I am at a loss to explain the behavior. Any help is appreciated.
The Ant script expects to find a Windows environment variable named SEAM_HOME.
To get the script to work...
Close any Command Prompts that are open.
Create a SEAM_HOME Windows system environment variable (if this step is unclear, search Google to find instructions on how to do this for your version of Windows).
Open a new Command Prompt.
Run echo %SEAM_HOME% in the Command Prompt to confirm that the environment variable is set.
Re-run your Ant script.
SEAM_HOME appears to be related to JBoss. For an example of what the value of SEAM_HOME can be, see this JBossDeveloper forum post.
What I'd like to do is to be able to add a tag to commits which Jenkins is building from. Right now I tag commits with the Jenkins build number but I want to also add in the app version as listed in the Info.plist CFBundleVersion in front of that.
What I want to know is, how I can grab that value using Jenkins or otherwise and be able to use that as a parameter/variable within Jenkins?
I've seen references to using plistbuddy to set this value so I would assume there's a way to use that to get the same value. Though how and how to get that to where I can use it in Jenkins I don't know.
For further clarification I am using Git Publisher in Jenkins to create a tag and push it with this format
jenkinsbuild-$BUILD_NUMBER
This results in a tag on the commit in git like this - jenkinsbuild-303
What I want, assuming my app is currently at version 3.5 is a tag that reads - jenkinsbuild-3.5-303
I managed to piece together a solution from the answer which #agy linked to. Here's what I did:
In the Build section for the Jenkins configuration, I added the following two lines to an 'Execute Shell' step after the Xcode step:
APP_VERSION=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "path to your plist")
echo APP_VERSION=$APP_VERSION > appversion.properties;
After that, I added an 'Inject Environment Variables' step (I think this is part of the EnvInject plugin), to which I added "appversion.properties" to the Properties File Path field.
After this is done, APP_VERSION is now available as an environment variable in subsequent shell command steps.
I'm trying to setup something with WebDeploy that will allow configuration of Environment Variables to set the "parameters.xml" parameters in a web deploy package.
From what I've read so far, this should be possible, but I've not had any success yet.
Essentially, it's TeamCity that I'm using to do it, but the concept is beyond a usage in TeamCity.
I'm using the generated cmd that you get from using the /t:Package target.
So my question is, is this possible? or is there another solution for iterating the teamcity variables and updating the SetParameters.xml (rather than manually coding an XML Poke foreach, or using /property syntax on the raw MsDeploy.exe).
You should be able to reference environment variables from the command line when you run the msdeploy command. I don't have experience with TeamCity but I suspect you give it a msdeploy.exe command to run.
This post gives more details - http://evolutionarydeveloper.blogspot.com/2013/05/specifying-environment-variables-at.html
I am writing a script to automate my iOS building. It will be run outside of Xcode, either via Terminal or from build automating software. Is there any way to have access to Xcode environment variables in my script, so I don't have to try and derive them myself?
For example, can I get access to PROJECT_DIR instead of assuming I'm in the current directory and running pwd?
I am currently hardcoding the product names for my different build configurations. (I'm also hard coding the build configs, but I could parse them them from xcodebuild -list.) Is there a way to get the app if you know the build config name?
(I saw this related question but it doesn't have an answer for me.)
The Xcode environment variables are only defined for child processes of the xcodebuildcommand-line tool.
One solution I used is to have a very simple script as part of my build process (Project->New Build Phase->Add Run Script Build Phase). All this script does is export the necessary variables and call a script in my path somewhere.
That script could be generated by your build script before calling xcodebuild and voilà! you have an external script that has access to Xcode build variables.