I'm sure this is a dumb mistake on my part but I can't find the right answer.
I have a project that has a snapshot dependency on another project. For sake of discussion website is dependent on toolkit.
Monitoring the build folder:
c:\programs\Teamcity\buildagent\work
I see the toolkit get built and the folders all exist as expected:
c:\programs\teamcity\buildagent\work\toolkit
Then the website build kicks off and the folder above gets deleted before the website build starts.
This results in the website saying the reference couldn't be found. What setting am I missing?
Using TeamCity 7.1.2, working on getting it upgraded to 8.1 but it requires some internal evaluation first.
Don't think its a version issue. How do both of your builds know where to put the artefacts at . For ex teamcity normally builds stuff at c:\programs\teamcity\buildagent\work****\toolkit , not at c:\programs\teamcity\buildagent\work\toolkit ?
Also, if your targets are dependent upon each other across builds, (1) have you setup any artefact dependencies or (2) any process that does not read of a shared agent workspace ? or (3) forcing both builds to run from the same directory
See if both your builds are running on the same target "folder name". In case they are , deselect any option that "cleans up build targets" before they run.
Also, you might want to check your build files to see if they have any code to clean directories before they start to run
Related
I have upgraded from Sonar 5.3 to 6.2 and a project X is giving me some weird errors at the sonar stage of the jenkins job (altough build finishes as STABLE).
The project is a standard multimodule maven java project.
Entering the project dashboard a single message appears on screen:
"No analysis has been performed since creation. The only available
section is the configuration."
But in the upper-right corner the red "FAILED" tag shows up. That leads to the Background tasks of the project and there is the failed task with this error log:
The project "com.foo:bar-submodule-1" is already defined in SonarQube
but not as a module of project "com.foo:bar". If you really want to
stop directly analysing project "com.foo:bar-submodule-1", please
first delete it from SonarQube and then relaunch the analysis of
project "com.foo:bar"
I do not want to delete the project and lose the historical data.
So the question is: How can i add a project Y (that is a submodule of project X but Sonar does not recognize it) as a submodule of project X?
EDIT 1
The parent project is the only one that has been analyzed through jenkins jobs.
Your problem is not that Sonar can't figure out your submodules, but the root issue is that there is another project/module with the same name conflicting with the project you are analyzing now. It happens, for example, when you extract a submodule as a standalone library and moves it as a root project and try to analyse the new project. Since it is a new project, but sometime in the past you had another project/module with the exact same name, it won't be able to finish the process. I have found three ways to fix this:
Delete the old project, if it is possible
This is a option that I use when I have analysed mistakenly new projects (with wrong parameters for example) or when I am migrating servers and still have some wrong configuration in place. You can do this in the project's Configuration/Administration menu, 'Delete project'.
Rename the old projects keys
This is my default option, since usually what I want is just keep the old analyses data for old submodules that we are moving to other projects or promoting to root modules. You can do this in the project's Configuration/Administration menu, 'Update key' option.
Updating your current project's keys
This option I use when the submodules conflict with other valid submodules (It can happen when you have different teams creating small libraries that happen to have the same keys). You can do this in two steps. First you need to update your project's keys following the option 2. The next step is to go to your project and update the modules and submodules names using the key sonar.moduleKey. The default value for this is : similar to sonar.projectKey, as especified here. Following these steps you won't lose all your records and old analyses.
I hope it helps.
We've got an agent build working on the main development branch from Visual Studio Team Services (VSTS).
With our agent build configuration set as:
This is working fine, the build agent picks up the source and builds.
Now, I want to make the build agent build the R5 code which is identical to the Main Dev Trunk code - newly created branch.
So in VSTS I change the folder to build to:
When a file is checked in it triggers the build. It builds no problem.
But for some reason I getting this error when loading the website.
"Could not load file or assembly 'classlibxxxx, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified."
The code is identical, so must some setting in VSTS?
Do I need to change anything else in VSTS, is the path correct, or what else could it be?
UPDATE - what I do notice now is that the log is telling me it is download all the sources (even for the previous R1-R4 releases)
Okay! Since it's way TL/DR to wade through the, what I'm finding is very poor, documentation for VSTS... Here is what was causing it:
The mystic _work directories of the agent... E.g. c:\agent\1,2 etc. are NOT output directories.
The website had been pointed to one of these folders and by some fluke must have been working.
What is needed is another step in the Build Definition to actually place the compiled files into something meaningful.
You need to supply an Admin Username and password even if it on a drive local to the Agent.
But hey presto, after 6hrs of madness... all the projects are lined up and will run without issue.
I have recently added a TFS build to our project, and configured it to run the automated tests that are in the project, and for some reason the build is ignoring the tests as if they don't exist!
In order to figure this out I created another solution with only a basic project from the origin code and the test project as well.
I've added these to the TFS and configured an almost equal build to this solution, and guess what? it executed the tests! it's the same tests as the original. just a copy of it.
The main difference between these 2 solutions is that the original code is a big solution with many projects, most of the projects are in some kind of a solution directory (and so does the tests project - it's inside a solution directory as well).
The difference between the TFS build definition is only that the output location of the build is set to single directory (I also tried PerProject and it worked) and in the original code it's defined to "AsConfigured" because we have some build tasks for copying dlls and such.
Has anyone encountered this problem?
Any ideas?
Thanks
TFS will look for the test DLLs in the BINARIES output folder location. You need to configure your 'build tasks for copying DLLs' to ensure your test DLLs are copied to this location.
Test assembly file specification
Specify the binary files that contain the tests that you want to run. Leave the default value (**\**test*.dll) if you want the build agent to search recursively for any .dll files that match *test*.dll in the binaries subdirectory of the build agent's working directory.
TFS2013 — http://msdn.microsoft.com/en-us/library/ms253138.aspx
TFS2012 — http://msdn.microsoft.com/en-us/library/ms253138(v=vs.110).aspx
I have a project which is a plugin for an opensource system. In order to run a CI build for the plugin, it needs to be installed into an existing instance of the main opensource system. I have mostly got this working, however, the install procedure for the main system is long and complex, so the build takes forever. It is also awkward to set up as checking out the plugin from git always happens first, whereas it needs to happen after the main system has been put in place so that the right directories are there. The solution I have right now is to use a shell script for the install and then an Ant task for the build, ignoring built-in VCS altogether. Feels hacky, though.
Two solutions come to mind:
Have a persistent install of the main system in the build directory, which the plugin is added to at the start of the build, and removed from at the end. I didi this ith Jenkins and it worked OK, but we are now using TeamCity.
Have some sort of parent-chid relationship between two CI projects, so that the main one is built and then triggers the plugin one, which is built within it. This would allow the main one to be rebuilt whenever it needs to be and avoids the awkwardness of keeping an install of the main system clean between builds.
However, I don't know enough about TeamCity to know if this is possible. Has anyone ever done something like this before?
For your solution number 2 you can try to use the "Build Triggers" configuration, the "Finish Build Trigger" option should resolve your parent-child relationship very well.
In TC, go to your plugin's build configuration, in "Configuration Steps" section select "Build Triggers" (number 5), then select "Add New Build Trigger" and configure "Finish Build Trigger" selecting your main system's build configuration.
To use parent directory in child one, you'll need to use the "Artifact Dependency" (see "Dependencies" section in "Configuration Steps", maybe setting some snapshots between the build configurations too.
Artifact Dependencies:
artifact Dependencies provide you with a convenient means to use the
output (artifacts) of one build in another build. When an artifact
dependency is configured, the necessary artifacts are downloaded to
the agent before the build starts.
Snapshot Dependencies: by setting a dependency of a build (e.g. build B) on other build's (build A's) sources, you can ensure that build B will start only after the one it depends on (build A) is run and finished
Configuring Finish Build Trigger:
finish build trigger triggers a build of current build configuration if a build of selected build configuration is finished
I'm having an issue with TeamCity, which relates to the fact that it runs the source control step before it runs the build steps. My project is a windows service, so there are complications with this.
TeamCity often decides to delete the entire contents of the project directory, even though I have the clean build option unchecked. However, since this is a windows service this does not fly, as when trying to delete the dll's it errors out since they're in use:
Error while applying patch: Failed to delete: F:\PathToService\bin\Release\Library.dll
The most frustrating part is that the dll's aren't even under source control, TeamCity seems to have a mind of its own and decides to delete them anyway.
Is there a way to get around this, to be able to run a build step BEFORE doing the svn checkout so that I can stop the windows service first?
I would try to set up your CI environment so it uninstalls the windows service once you are done testing it. I am not aware of Teamcity pre-checkout hook.
The answer was to split up each service into a separate working directory. That prevents teamcity from deleting the dll's.