I have created a Smart Device CAB Deployment Project and contains dependencies eg: Test.dll.
Where Test is a seperate class library. I have created a build definition for this solution(contains Test Proj + CAB deployment Proj). When i trigger queue new build for this definition Test.dll is not getting updated in CAB deployment project in Build Agent folder of TFS Server.
PLease let me know how can i reload this dependencies on checking in / queuing new build.
Thanks in advance
Check your Workspace option on Process tab. It should be All or Outputs if you wish to have always fresh version. None option is for incremental builds. If your project is really small "All" is the best option for you.
All - erase entire workspace and download and build everything again
Outputs - like All but only output bin folders are erased and new
version is downloaded (get latest version) from source control.
(incremental get) (like Rebuild (cleen + build) in your solution)
None - sources are build incrementally. Like Get latest version +
Build command in VS
Related
We use TeamCity 10.0.4 (build 42538) and want to migrate to the latest version (2022.04) with all our build configurations but without the build history. We saw here https://www.jetbrains.com/help/teamcity/how-to.html#Copy+Manually that:
If you want to do a quick check and do not need to preserve the build
history on the new server, you can skip Step 6 (cloning database) and
all the optional items of Step 4.
Unfortunately by doing this manual copy we were not able to run the new instance without cloning the database, as we got the error on the image below.
We then did a "Restore from backup" (from the image below) by doing a "TeamCity Backup" (Administration > Backup > Run Backup) of the server settings, projects and builds configurations, with no more success.
Do you know a way to migrate to a newer TeamCity version by keeping all the build configurations and removing the entire build history ?
You could try to export/import current projects:
Export to zip archive via Actions button or manually backup teamcity_data_dir/config/projects folder
Install fresh new TeamCity server
Copy your backup to teamcity_data_dir/config/projects
What is the set up required to move files between builds in TC? I am needing to move both modified source files and build binaries between the build configurations of a build chain.
I have 1 project with 4 builds. The builds are
Update Version Number (This build updates 15 sources files)
Compile (This build compiles a dozen objects)
Test (This build runs a regression test)
Create Package (This build creates a setup.exe file)
Information about the TC setup and chain
I am using perforce as my VCS.
All 4 builds use the same VCS root.
On all 4 builds under version control settings I have "Clean all files before build" set to "On".
"Update Version Number" build is triggered by any check in to the VCS. (This works)
I have been able to successfully chain and trigger the builds. However each build starts with a fresh copy of files from the VCS.
The chaining is set up to use snapshot dependency.
Based off of the TC documentation it looks like I should be using snapshot dependency and not artifact dependency. If I put the build steps of all the builds into the same build everything works. However we are looking to have more flexibly and expand on this build chain in the future.
I tried setting up the configuration so only the first build is attached to the VCS root and the other builds don't have any VCS root. This didn't work.
I have been unable to find the answer googling but I have been able to find someone else who is struggling with this problem. Sadly they didn't receive an answer.
After speaking with TC customer support I learned the correct technique is to use both artifact dependency with "build from the same chain" selected and snapshot dependency.
I have a TeamCity build configuration where step 2 is packing a NuGet package and step 3 is publishing the NuGet package to an external build server.
At least that was my intention.
When I omit step 3 the build is success and the package is created and placed in the directory I specified in step 2.
When I include step 3 it fails because TeamCity has not yet placed the created NuGet package at the specified destination.
Am I approaching this the wrong way, do I perhaps need another build configuration with publish that depends on the first build configuration ?
It turns out when packing NuGet packages to an external resource like I first did, example \\foo-server\temp\\nuget the NuGet packages would not be copied to the destination until the build was complete, after step 3 should execute.
Solved it by just using 'nuget' as destination directory, creating a temp folder in the checkout directory of the Build Agent. By doing it that way the packages are available inside the build configuration so step 3 can access them.
i have a problem to distributing application with 2 project (one project with sub-project include inside). When i try to make as usual "archive", i'm not able to send application.
Could someone help me?
Regards
I'm guessing the sub-project is a library? And when you do Build > Archive you get an .xcarchive file instead of a .ipa? If so, you need to set the Skip Install flag to No on your library (see this answer), then Build > Archive will generate a .ipa file.
The reason this is happening is because you have two projects.
For the sub-project you need to edit the Target > Build Settings and set the Skip Install setting to Yes.
Afterwards the "Archive" action will work as usual.
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.