For example, project A generates two artifacts processor.exe and t.txt. Then in project B, can I add a build step to execute processor.exe t.txt?
I know there are two Runner types(.NET Process Runner and Command Line) that can execute programs. But how to get the paths of these artifacts?
Yes, I think it should be possible to run with Command Line runner *.exe file generated by other build.
You just have to make sure that build agent which runs Project A outputs these artifacts to place where build agent which runs Project B has access (in case if you have single agent it's not a concern obviously). And probably placing these artifacts into agent's working directory is not the best place because it can be cleared by doing clean checkout from VCS. Just choose some generic directory on the server and specify it for artifact output in Project A and then for Command Line runner in Project B.
Related
I have TeamCity installed on centos. I have only one Linux BuildAgent for now. My build configuration execute a maven script and using ant upload WAR artifact to Windows Server on FTP. After this step i have to execute BAT file on remote Windows Server. I read that i can do this using psexec/RemCom, but i can't understand how i can do this in TeamCity? Build Step or different Build Configuration should contain steps to execute psexec/RemCom or i can insert Build Step into existed Build Configuration?
Single build configuration could potentially consists of multiple build steps. Think of them as a actions you would like to do. So I suppose that right now you have a maven step in your build configuration. I would suggest you to add Command Line step, where you can do what ever you want -- it's like bash/batch script. You can put script contents directly to the build step, or you can write script and execute it.
But as you mentioned that you have CentOS, it could be you have to do extra configuration on the build agent for PsExec to be available.
I have situation where i am running 2 maven commands back to back to run 2 different set of tests.
However i need the final target folder to have results of both maven commands. Problem is that the second maven command cleans the target folder. Is it possible to ask mvn to not clean a specific folder in target.
I have a Maven project which performs a number of time consuming tests as part of the integration-test Maven cycle. I'm using Jenkins as the CI server.
During the integration test a number of files are produced in the target folder. For example, an "actual" BMP file is produced and compared to an "expected" BMP file. If the test fails, I need to look at the files in the target folder to determine how to deal with the error. Maybe the actual BMP looks fine and so it should be promoted to the new expected BMP. On the other hand, it may reveal a problem that requires a code fix.
The thing is I don't have any way to get access to these files, other than to ssh into the CI server and manually scp the files over to my own machine for closer inspection. It would be extremely helpful if I could access these files from the Jenkins web interface.
I tried using the build-helper-maven-plugin to attach the relevant files as Maven artifacts, but the problem is that there is no suitable phase in Maven that executes after an integration-test, if any test fails.
What can I do? Can I use the "Copy Artifact" plugin for this?
1) The files in the target folder can be accessed using a link such as /ws/projectname/target/filename...
2) Rather than typing the url each time, the SideBar plugin can be used to add a link to the file to Jenkins' left menu, making it easily accessible.
You need to copy your files into your workspace in a build step and archive them from there - Jenkins lets you specify artifacts only relative to the workspace.
I usually create a directory keyed by the BUILD_ID in the workspace, so that artifacts from different builds do not get mixed up in case I do not clean the workspace and archive from there (specifying ${BUILD_ID}/**/* in the archiving step).
In case your build fails before it can run the copying step and because of it does not do the copy, take a look at this question.
I have a build step that builds my projects and packs it into a myfile.jar and put it in my artifacts dir.
i have also told jenkins to archive the myfile.jar.
now i want to add another build step to execute shell command java -jar myfile.jar and install it for further testings
how can i tell jenkins to point to myfile.jar when executing the shell command ? i don't know the artifacts dir name since it's dynamically created with build number etc...
thanks.
The artifacts directory is on the master, not the slave.
If both are on the same machine for you, the artifacts reside at:
$JENKINS_HOME/jobs/$JOB_NAME/$BUILD_ID/archive
However, like Anders Lindahl said, archiving an artifact does not delete it from the workspace; why not use it directly from there. Generally, you do not want to disturb the archives directories...
i'm new to world of continuous integration and software developement.
I wanted to try hudson so i installed it on my ubuntu machine and created a new job. i pointed it to an open source project's svn (keepassx) just to try.
Hudson downloaded everything from the repository and marked blue for successful build.
aren't i suppose to be able to execute the software now somehow ? i thought once it is built i can run it, but i can't find any executable in the project's home page under hudson user home dir.
thanks.
A Hudson/Jenkins build breaks down into three steps:
update source code in workspace
run build
publish build artifacts
It sounds like you've got step 1 covered.
If the project you linked to has instructions for building (ant, maven, etc.), you can enter these as build steps into the "Build" section of the project configuration.
You can then take the resulting files ("artifacts"--jar, exe, so, bin, whatever) and publish these using the "Post-build Actions", or if necessary you can grab them directly from the workspace filesystem.
Assuming the build artifact was an executable, you could then run it after downloading it from Hudson, or make a build step or post-build action which moved it into the appropriate location and ran it.
It helps to run the build locally before trying to get Hudson to handle it--then you know what the build steps are, and what the final build artifacts are.
How would jenkins/hudson know how to 'execute' some arbitrary package that you told it to download and build? It's up to you to write a program or script to run what you want to run, and then make a downstream job (for example) to do so.