I have a project in eclipse, a library that has an applicationContext inside a package "net.xxxx.xxxxlib.core.config", inside that package there are two things, a class and the applicationContext.xml. In local everything compiles correctly, I pass the corresponding maven tests and I make the build in Jenkins with a success result.
The build in jenkins triggers two actions:
On the one hand the jar is uploaded to a JFrog Artifactory updating its RELEASE version, when I access the RELEASE to its "xxx-RELEASE-sources.jar" and go to the path where the applicationContext has to be, it is in place, so far so good.
On the other hand the project is compressed in a jar and uploaded to a shared directory so that any authorized application can use it.
It's in this second step where I find the problem, when I open the jar and go to the path where the applicationContext should be, it is not there.
I have seen in other similar problems that suggest to change the applicationContext to src/main/resources, for requirements beyond my control this is not possible in my project.
I don't know if the information I have given will be enough for anyone to think of what might be happening. I am still grateful for any suggestions.
Related
I'm using Jenkins 1.646. I keep getting Unreadable Data entries in the Manage Old Data section.
These entries appear for pretty much every build that occurs on my Freestyle projects. The builds complete just fine. Does anyone have any idea what I need to do to correct this? I did install the Pipeline plugin recently, and it installed a dozen or so other plugins with it, so my guess is that something is incompatible with my version of jenkins and / or another plugin I have installed.
I think I figured it out. I found out that VariableInjectionAction is a domain specific class inner class we are using in one of our build steps. We are dynamically loading its parent class to the classpath using the GroovyClassLoader for each build. It would seem that jenkins is trying to keep track of all the classes that are used to run our groovy scripts for a particular build, and since this is a dynamically-loaded inner class, jenkins is unable to find the class for archived builds, thus giving the error above.
I assume the error would go away if we loaded our groovy scripts differently, e.g. pre-compiling them placing them on the root jenkins classpath. For now, since the builds are running fine, we'll probably just live with having to cleanup the unreadable data periodically.
Also, this obviously didn't have anything to do with conflicts with recently installed plugins as I first thought.
I have set up a TeamCity partly. Now it downloads the code from TFS and try to build it using MSBuild which was not successful. I know that I am doing something wrong. I have some library added to my code(An ASP.NET website). I know that it is not a good idea to add dll files to Version Control(TFS), but if I don't check them in, when TeamCity downloads the code, it does not have that libraries so MSBuild cannot successfully build it. I was wondering what would be the best practice to solve that issue?
For dependency management in .net I would recommend that you take a look at the TeamCity built in nuget feeds. You have a possibility to utilize a feed directly from within TeamCity, acting as a server. As you state, commiting dependencies in (any) VCS should really be avoided...
It depends on what type of dlls you're dealing with.
If they are available on NuGet.org, use NuGet and the Package Manager Console to add the references to your solution. Then just put NuGet.exe on your Build Server, and run
NuGet.exe restore YourSolution.sln
As your first build step.
If they are in-house dlls, then you have a few options. The first being, as TeNGiL mentioned, setting up a private NuGet repository, and publishing the in-house dlls, to that feed, and pulling from it within your build server.
The other option is just to create a 'References' directory in source control, which holds dlls, reference them in your solution from the source controlled directory, and then pull them down as part of your Build Configuration. This really isn't as bad as it sounds, within reason, and is a perfectly acceptable interim solution to incorporate until everyone is on board with using a private NuGet feed, or something of that nature.
Open the code in the checkoutdirectory of TeamCIty in visual studio and try and build.I am pretty sure that visual studio will give you the exact error message of what's going wrong.
Missing packages have to be restores. Use a Nuget Installer build step to restore your packages as given in image below.
I was wondering if anyone could help.We have the following project structure in our company :
Code/Common
Code/Project1
Code/Project2
etc...
When the Common Project builds, it has a PostBuild Event that copies all the relevant files into the Code/Common/Binaries folder. Then all the other Projects reference the Common components in this folder.
However, what we are struggling with is that when TFS Online checks-out the solution it does so to c:\a\src and the Common binaries are placed in c:\a\src\Binaries. Now, when the other projects (Project1 etc) do their build it cannot find the Common Assemblies, as not only are they removed, but the paths are different from what it expects them to be in c:\a\src\Common\Binaries instead of c:\a\src\Binaries.
Is there anyway to tell the build server to not delete those files in the "Binaries" directory and to specify the folder location to checkout to? Or how one one go about solving such a problem?
Thanks very much
A build server is a transient thing, you cannot rely on files to be there.
You need to either Create Nuget Packages for you common output and then consume these in your other projects (the 'proper' way), or you will need to check your dependencies into source control after each build so you can then reference them in subsequent builds (the 'really frowned apon' way).
I've added an svn:externals to my project, and it works great locally via TortoiseSVN. When I use Jenkins to pull from the same repository, it's not showing anything about the externals in the console output.
I read some other questions on here and I made sure my SVN version number in Jenkins was set to (1.6 externals to file) and restarted Jenkins. The problem is still occurring. Any ideas of something else I could set, or something I could use for troubleshooting? Thanks.
Oh, and the external directory is in the same repository, so I don't think it's an authentication issue as it builds fine without a reference to the external files.
I fixed this issue by selecting higher SVN Version Number on Jenkins 2.222.1.
Here is the procedure:
Manage Jenkins -> Configure System -> Subversion Workspace Version
Select at least v1.6. (The default one was 1.4 for me)
I may have had a very uncommon structure, but here's what worked for me...
First of all, here's the directory structure:
--Parent
----folder1
------subfolder1
------svnexternalfolder
----svnexternalfolder
As you can see, I had my svn external folder in two different levels of the project structure, but the Jenkins project was pointing directly at "folder1".
When first configured, it would never pull the files for my svn external folder (whether it was a full checkout, or svn update). This was configured with the svnexternals at the parent level.
My next try was to remove the svn externals at the parent, then specify just the higher location on the parent, then the lower location on folder1. This gave an error since the child svn directory had the same name as the other one.
So I flip-flopped the order of creating the svn external locations and did the child first (on "folder1"), then did the higher one on parent. Once I did that, everything started working.
Hope this helps someone else.
If you're curious about why I configured the directory structure this way, this was a PhoneGap project. apparently cordova/phonegap projects create their directory structures like this, the common folder beneath the parent is the "www" which houses all html, javascript, etc files, then those are also used under the platforms/ios, or platforms/android folders (in my example, I just called it folder1).
Having real problems creating artifacts in teamcity 6.5 (using TFS & MSBuild as the buildrunner if it makes any odds, which it probably does as any examples I find seem to use SVN...).
The Build works, so long as I enter no checkout rules.
If I understand it, I'll need to set up some artifacts, that themselves rely on checkout rules(?).
I have two builds that are identical other than the way they are kicked off.
One is initiated on check-in
One is initiated manually from within TC. This build is the Test Build
Assembly version numbers come from a single versioninfo.cs file that is a linked file in all projects in the solution. This method is detailed here : http://www.codeproject.com/Articles/328977/The-Right-Way-to-Version-Your-Assemblies and holds the version number thus:
[assembly: AssemblyFileVersion("9.1.0.0")]
Ultimately, I'm unable to copy the output of the test build to another location.
As it stands, the only output of a build is in the teamcity data directory, for example :
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project1\bin\Debug
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project2\bin\Debug
etc
I'd like to copy the output files (exes and DLLs) to an output folder which has the build number of the build on it
For arguments sake, lets say for the version number above, this would be to
c:\BuildServer_Output\SolutionName\9.1.0.0
Currently I have not been able to create artifact paths that actually do anything - i.e. to copy anything anywhere.
For instance I have acoupe of artifact paths, but nothing ever gets put into C:\BuildServer_TestBuilds -
+:Accounts\bin\debug* => C:\BuildServer_TestBuilds
+:BackOffice\bin\debug* => C:\BuildServer_TestBuilds
Am I getting no artifacts (and my artifact paths therefore ignored) because I have no checkout rules?
Any help would be appreciated.
I am pretty sure artifacts and checkout rules are completely independent. Artifacts just deal with what has been built. Checkout rules tell teamcity how to react to and checkout changes in the VCS.
It looks like your artifact paths are beginning with absolute paths. I have always found it easier to use relative paths with wildcards. That way I don't need to worry about where teamcity put the build. We use the following to get all dlls and exes to one folder
**\bin\Debug\*.*=>deploymentdir
Our build configuration page has an artifacts link and when we open it it will have things like
deploymentdir\common\bin\debug\common.dll
deploymentdir\common\bin\debug\common.pdb
deploymentdir\runner\bin\debug\runner.exe
In one of our other builds we use an msbuild script to flatten our output before putting it through the artifact process.
We do use checkout rules but we have not had to change our artifact paths to accommodate them.