Recently I started to use Codeship as CI/CD tool for a small website that I am maintaining. I set up my Codeship project to deploy via sftp as described in their guide here.
The part where it fails is in the production script. I created a deploy folder and a production.sh script which contains the line:
put -rp "${HOME}/clone/build/*" /path/to/remote/dir
However when running the build I get the following error:
sftp> put -rp "${HOME}/clone/build/*" /path/to/remote/dir
stat ${HOME}/clone/build/*: No such file or directory
Echoing $HOME in a test script directly in Codeship gives me my home directory, so the environment variable works. However, at the moment the batch script is run, the environment variable is unrecognized.
How can I fix this? I'd rather not hardcode the path in my deployment script. It also doesn't seem possible that this happens because I suffixed production.sh, whereas in the docs they only have a production script?
With no answer coming from the people from Codeship, I resulted to writing the absolute path to the ${HOME} directory. I've been doing this for a time now with a few different projects and it all seems to work.
replace ${HOME}/clone with ~/clone
this worked for me
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
We have a Code Composer Studio (Eclipse) project that uses CMAKE to generate makefiles and build. The project compiles as expected when the project is manually imported onto the Jenkins slave (Win10 x64) and executed from the command line but fails when the build is handled by Jenkins. The failure always follows the same pattern: a singular letter is dropped from the path of an object file. For example, [Repo directory]/Cockpit_Scaling_and_Exceedance_data.dir becomes [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir and linking fails because it cannot find the referenced object file.
I made sure that there are no differences between the account environment variables and the system environment variables and have also configured the Jenkins Service to use the admin account on the slave instead of SYSTEM in order to get rid of as many differences between Jenkins and the command line as possible.
The project will build successfully using one of our other Jenkins slaves (also Win10 x64), so we know that it's not a Windows 10 issue or a problem with our Jenkins configuration. Since I can't find any differences between the configuration of the two slave machines, I was hoping that someone might be able to suggest somewhere to look for this path issue.
I never found out why the paths to object files were being mangled, but I did get the project to build successfully on the slave via Jenkins. All I did was change all of my system environment variables into user environment variables. I copy-pasted, so I know that the variables themselves did not change.
I have no idea why this corrected this issue as I had inserted a whoami call at the beginning of the build to confirm that Jenkins is indeed running as a user and not System. I guess from this point on all of my environment variables will be specific to a user and not SYSTEM...
EDIT: The problem has returned. I have made no further progress in tracking down the cause behind this issue, but I have found that I do not see this symptom when running the scripts in a bash environment instead of a Windows command prompt. Fortunately for me the scripts have all been written in such a way that they can be run in both environments, so I have had my coworkers use bash instead for them.
I have a series of frontend tests written in CasperJS that I need to run in Jenkins. Here is command I run from the command line: casperjs test ./src/tests/**/ts_*.js --xunit=xunit.xml. This runs the tests and saves the xunit file. Ok. When I have Jenkins run the same command it gets through loading the first test page and spits out this error: "Process leaked file descriptors" and directs me to: https://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build
It provides an explanation and a few OS specific work arounds. The environment this will be run on will eventually be linux however my development environment is Windows and I don't understand the workaround they provide. What kind of file is that and how does it fit with Jenkins?
Does anyone have experience running CasperJS tests using Jenkins?
I installed jenkins as a service and use default settings.
I solved same issue on windows.
if you are running as a service and default home directory ( c:/program files(x86)/jenkins/ )
you have to change path to other normal folder(ex.c:/jenkins/").
SET JENKINS_HOME=c:\jenkins\
What I do with jenkins and casper:
I create a job with string parameter 'tests', which takes *.js or specified test
and try to run casper tests via Build -> Execute shell
cd ~/test_directory
casperjs test ${tests}
When working with the .travis.yml, is there an environment variable that contains the name of the current build directory in Travis-CI? Looking through the docs here I don't see one.
You probably want $TRAVIS_BUILD_DIR, which is the directory we clone the repository to and cd into afterwards, before running your tests.
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.