I am completely new with Jenkins and have this question. So I created two projects on Jenkins. The first project will fetch from github if it notices any kind of change on my repo and will store a local copy on my machine.
The second project will start only if the first project is stable. If it is stable, the second project will first compile the all the java files (which I put in a compile.bat file), then it will run the testng.xml file which runs junit test and selenium test (run.bat file).
So what I want to do is if there is no compilation errors on compile.bat, then proceed on run.bat, but right now even though there are some errors on the java file and when the compile.bat runs, it catches those errors, Jenkins still proceeds to the run.bat file and at the end passes the build. I want the build to fail when there is any kind of errors.
Here is the link to my repo for the batch file and other files if that helps:
https://github.com/na2193/Demo
I had figured it out. You need to use conditional step(single) and there you can define what you want to do
Related
I have an established CI pipeline comprising (prior to deployment):
TFS build
JFrog Artifactory for build artifact management
SoapUI and SpecFlow (BDD & itaretive, parameterised) for web service functional test automation
I have no access to our build agent servers and no permission to install anything thereon. Instead, I've added the SoapUI binaries as links to my functional test project; the binaries are pulled from source control in the Get Sources step of every build.
This works okay but it greatly increases the footprint of my test project (and any other test project for which SoapUI would be required), and by extension, the execution time of the build: functional testing will only execute on a small fraction of the builds executed (only if application codebase has changed or sufficient time interval since last full build and test has elapsed).
For these reasons, I opted to remove the SoapUI binaries folder from my test project and instead deploy a SoapUI binaries zip archive to an Artifactory repository. With the addition of a PowerShell script step in my build definition, I can pull the SoapUI binaries as needed and extract to the desired location on the build server. Foolishly, I thought this might be straightforward...
I did manage to push the zipped SoapUI binaries folder to the Artifactory repo, and, in my Development build definition, I did manage to correctly script my PowerShell step to pull the zip archive and extract its content successfully to he same folder in the build binaries directory on the build agent server as it had been located originally.
However, when I execute my build, in the step where the SoapUI tests are executed, on the first test iteration, I see the following error returned to build console:
System.ComponentModel.Win32Exception: The directory name is invalid
I added a PowerShell scripted filtered folder content step before the test execution step in both my Development (new) and my Production (original) builds for comparison. Both show the required 'testrunner.bat' to be present, in the same folder on the build agent server.
The test project itself has been unchanged (except for the removal of the SoapUI binaries folder).
To summarise:
I'm trying to execute SoapUI tests in two builds; in each build, the same test project is used and the SoapUI binaries are in the same location when the test execution kicks off.
One build executes successfully without issue.
One build fails at test execution step, returning error "System.ComponentModel.Win32Exception: The directory name is invalid".
I'm very puzzled by this; insights and SoapUI wisdom most welcome.
Thanks for looking.
Turned out, there was a discrepancy in the directory paths on the testrunner.bat between the builds; a '_' where a '-' should have been
New to Jenkins so apologise in advance as I'm sure this answer is out there somewhere. Just not sure exactly how to search for what I'm after. I'm struggling a bit with the copyback process in Jenkins.
When I build, I'm running some unit tests that create some log files which I want to be stored as part of the Jenkins build. I'm running on Windows 10 and everything is running on my laptop (I'm purely trying to learn Jenkins so this is fine for me).
So my test results will always appear in C:\TestLogs\*.log. I want the results copied to my build directory which is URL: http://localhost:8080/job/loadrunner_test/1/ absolute: C:\Program Files (x86)\Jenkins\jobs\loadrunner_test\builds\1
I'm a bit confused with which plugin I should use in my post build step? Copy Artifact plugin looks as if it's meant to pass data between builds. For each build, I just want to copy C:\TestLogs*.* to the current build directory so I can see them when I click on the link for #1 in the Build History.
Many thanks!
Tim
WindowsDir
Jenkins Build
You can copy it with additional step.
Select Execute Windows batch command for that step and add this line:
xcopy C:\TestLogs C:\Program Files (x86)\Jenkins\jobs\jenkins_test\builds\%BUILD_NUMBER% /s /e
You can also check configuration for your test if you can set path location.
I have been tasked with looking into using Jenkins as a build server. So far I have managed to pull a project from git, restore the Nuget packages, build the project and run the unit tests. However I am struggling to find out how to generate the artifact.
The way the business would like to have the build server generate a zip file to a directory on the build server or a remote server for the systems team then to pick up and deploy to the relevant location. E.g. given a windows service project the built bin directory would be zipped up and put in the relevant artifact directory.
I thought that in order to do this I add an archive the artifacts post-build action. However I am getting the below error:
‘Watchdog.WinService.Monitor/bin/Release/*.zip’ doesn’t match anything:
‘Watchdog.WinService.Monitor’ exists but not
‘Watchdog.WinService.Monitor/bin/Release/*.zip’
If I look in the workspace for this project I can browse to the bin directory and see all the files so I unsure what I have done wrong.
Can someone please let me know if what I am trying to accomplish is possible, and also if our approach to using Jenkins is correct?
The problem is that you try to create the artifact using the archive artifatcs step.
But the step is to collect artifacts and show them on the job page.
That means you need to create the artifact first e.g. using a shell or batch script.
You can combine this with the Flexible Publish Plugin.
When you select this as post build step you can create a conditional action that runs the artifact archive task and as condition executes the script that creates the zip file.
So if that fails the task won't be executed. Also it may causes your job to 'fail' but that may not be the case in your job.
I seem to be getting a lot of pain with the processing of app.config and token files (we have this working with the older ".11" templates).
It looks like currently (using the ReleaseTfvcTemplate.12.xaml) this is running the tokenisation after the build.
While I can make the app.config / myapp.exe.config stuff work by deliberately copying the .token file into my output folder (so the recursive search finds it) this feels pretty horrid.
As a fix I'm tempted to move lines 182-230 to just before the RunMSBuild task on line 175 (creating a new sequence at that point)
Is this the correct approach or have I missed some documentation somewhere (or a later version of the template?)
Thanks guys... Anyway for future reference I did make the change.
However I had misunderstood the exact nature of the order things happen out of the box which is as follows:
Get the project out of source control
build with msbuild
Copy the .config.token file over the .config file. This is in the TFS template
As part of the deploy to a server then the token entries in the .config files are replaced. This is in the release manager template.
Tests are run in the msbuild binary output folders.
The problem is this doesn't really work if you're using an project type that uses app.config file as the msbuild process renames these output.exe.config during the msbuild stage so you need to create both an output.exe.config (marked as copy to output) and an output.exe.config.token so when the post deploy is the final output gets configured correctly. This also a problem if you want to tokenise some mstest dlls as these typically use an app.config as well. Basically this is a bit of a mess unless you are using web.config.
We worked our way around this by using the modification I suggested above (you need to create a sequence at line 175 and move lines 178-230 up into the sequence, this is GetBuildDirectory variable bits and the if statement) followed by adding an additional deployment stage which copies back onto the build server with the new tokenised files so the mstest can run against them.
So our new process looks like this:
Get the project out of source control
Copy the .config.token file over the .config file i.e app.config.token copied over app.config
build with msbuild (this means we end up with tokenised myapp.exe.config and mytests.dll.config)
As part of the deploy to a server then the token entries in the .config files are replaced. This is a release management step in the release template.
Deploy the tests back into a folder on build server (think this has to be a fixed folder until update 4 of release manager is deployed) the token entries in the .config files are replaced (so our integration tests can use the newly deployed servers). This is a release management step in the release template.
Tests are run in the fixed folder on the build server (rather than the msbuild output directory) so the test wildcard needs to be changed in the tfs build template.
Quick final note we don't use that build directory variable and it's left at blank I'm not convinced this would work if it was set to a value...
The replacement of variables in config files with Release Management happens at deployment time and not at compile time.
When RM deployes your app it inserts the correct variables.
It sounds like you're hitting one of two issues:
You need to include the .token file in your project and make sure it's set to Copy Always, so that it gets copied to the build output folder.
If you're building a web application, I've seen a bug in the release build process template that doesn't touch the contents of the _PublishedWebsites folder. I don't know if it's been fixed in Update 4 or not, but it was definitely still a problem in earlier versions.
I am new to Jenkins and just started configuring it. This is what i have done till now:
Installed and configured Jenkins to display the home page. Added PMD plugin.
Set the HUDSON_HOME to a specific directory > C:\Work\Jenkins
Configured a test build to run a simple do-nothing ant script. It runs successfully
Written an independent pmdbuild.xml to run checks on a set of files in C:\myview (I am using clearcase). This xml also copies the output pmd_results.xml to the workspace directory in $HUDSON_HOME/[job-name]/workspace
Now I added the pmdbuild.xml as a step in my primary build. So my build has 2 steps:
a. Run a simple script, do-nothing.
b. Run pmdbuild.xml which generate pmd_results.xml and place it in $HUDSON_HOME/[job-name]/workspace (HARD-CODED as Jenkins PMD plugin expects the file there)
Jenkins picks up the pmd_results.xml automatically with the plugin and displays warnings and everything.
Now the problem:
If I click on a filename in the PMD results, it gives a filenotfound exception as it is looking for the source file in $HUDSON_HOME/[job-name]/workspace.
My java code files are placed in C:\myview (a clearcase snapshot view)
My question is, do I need all my code files to be present inside $HUDSON_HOME/[job-name]/workspace ?? Meaning can't I tell Jenkins to look for the PMD input files in C:\myview or any other directory instead of $HUDSON_HOME/[job-name]/workspace ??
Sorry for the extremely long description.
Jenkins expects that all the code is in the workspace. Usually Jenkins is used to check out a copy of the code into the workspace, and then runs all build steps on the Sources in the Workspace.
Might seem restraining at first, but it saves you a lot of trouble if you need to move Jenkins to another server, or create a slave instance.
So I would suggest you let Jenkins check out your code (there should be a clearcase plugin) into the workspace, and run the analysis on the checked out code.
If there are compelling reasons why your code has to stay where it is (C:\myview in your case) you can still set the workspace of your build to that directory (find this in the job configuration page, you need to click on the 'extended' button to see the option).