I have a standard build configuration, ending with a simple ssh copy of the output files to a remote server.
The process wanted is simple:
The developper pushes the commit to production
Teamcity builds the product
The developper downloads the product from the remote server where build results are stored
The developper tests the product (end-to-end testing, testing setups etc, can't be automated at the moment).
If the product is okay, label the build that produced this output as the new version (let's say 3.2.1).
Teamcity applies the label, and moves the files produced by this build to a folder named after the label value (3.2.1 in this example).
Only the last step is missing, because I don't find any ways to connect on the tag action to trigger some sort of build action.
I already tried to link another build configuration to this one, but the issue is that it has to be triggered by the developper for a specific build ID, so the developper tests the output of a given build, if it's okay, he tells teamcity "Okay, release this build as version 3.2.1" and the build artifacts are persisted in a folder named 3_2_1 for instance.
Related
Context:
Currently we manually get a git dev branch built into a package into VSO, and once that package is built it deploys to Octopus and takes down the site for a good amount of time as all the built packages are loaded into each server the site sits on... But, honestly, a lot of the bug fixes end up being in js files that could easily just be hot swapped in... and it's just so annoying to have to wait for poor OPs and support to do all of this just for a teensy tiny change.
The pipedream:
I would like to set up CI that allows hot swapping of js,css,cshtml,html files to VSO and Octopus... This will allow small petty changes in javascript files to be issued out fast and without deployments...
...and also have another option that allows me to say, "look, i've changed some csharp files so i need a built package to be pushed up into VSO and Octopus". A manual rebuild if you will.
Question:
I'm missing the vocabulary to search for this in Google and wondered if you guys can help me on a path to setting this up.
You can just include the modified files (remain folder structure) in the package, then push this package to Octopus server and deploy with this package, then the necessary files will be replaced.
My workflow of IIS deploy:
New Deployment Target with Listening tentacle mode
Add Deploy to IIS process template for Octopus project
Enable Custom installation directory feature in Configure Features window of Process
Specify Custom Install Directory path in process
Build tasks:
Add Copy Files task to copy necessary files (e.g. js)
Add Package Application task to package these files (remain folder structure)
Add Push Packages to Octopus task
Add Create Octopus Release task
On the other hand, you can include all published files to package (tested with File System publish), then deploy with that package, the Octopus can compare files and just replace the modified files ({webapp}.dll will be replaced too, checked the Created, Modified time on target server)
Regarding get changed files during build, you can call Get commit with Changed items REST API, then create/modify the build variable (e.g. depAll) through Logging Command (e.g. PS: Write-Host "##vso[task.setvariable variable=depAll];]Yes") per to the changed files result, then using this variable in task condition (Control Options of each task) to determine which tasks need to be run. Specify conditions for running a task
I am new to Jenkins CI tool and I want to know if it is possible to specify what build to use when there are several projects, on different SVN locations, dependent on one another. For example, if I have the web project on SVN location1 and the backend project on SVN location2 and the web depends on the backend and one of the developers modifies something in backend, when the web developer does a commit, there will be a build failure. Is there the possibility to specify that the build from the web part should take into consideration build x from backend and not the newest build?
Thanks in advance.
yes that can be done. in Jenkins check for the Build Triggers options in your project web-settings and on the line Build after other projects are built you can specify the name of projects you want to build automatically after there has been changes made to the base project.
And similarly, in the Post-build Actions, look for Build other projects, where you can specify that if the base project builds successfully, it will automatically trigger a build on children projects.
Hope this helps.
Your example of building a project against a specific version of another project is a little non-standard, but not impossible.
In your case, I would use Jenkins' ability to execute arbitrary scripts to help. The script would take care of getting the correct version of the project that the one I want to build depends on.
Building on your example of a Web and Backend project, here's how I would do things without using a parametrized build:
Add a file to the repository of the Web project that stores the version of the Backend project to use
Configure a job to build the Web project when the source for the backend project changes in SVN.
The project should check out the latest version of the Web project
The first Build Step for the project would be a script (Execute Shell or Execute Windows Batch Command) that does the following:
Gets the version of the Backend to use from the file containing the version info
Either pulls the appropriate version of the Backend from the Backend's repository; or pulls the source of the appropriate version of the Backend's source
(If you pulled the source only for the Backend, the next Build Step should be to build the Backend next)
Build the Web piece
Do any unit tests
We are using bamboo as our integration server. During each build it produces binary packs of our products. Some of the built artifacts then goes in to QA.
Is there a way to retain build artifacts of a certain build job number, irrespective of the global build expire configuration. For an example, at some point we identify one of the built artifacts as release candidate.
The QA should be able to download that specific pack even after one weeks time. Right now we are copying the build artifacts from CI server to some other machine. It is a script, but still it is a manual process.
In Hudson there is an option called 'keep this build forever'.
Depending on your version this is possible by applying a label to it. Under a plan's configuration on the "Miscellaneous" tab, you can set a label which can then be used to prevent a build from expiring.
For example, our system has builds that can get labelled "SaveBuild" which then prevents their expiry.
I've started using TeamCity personal builds, via the new Git remote run feature in TeamCity 6.5. Doing a single build works fine; I have a project that compiles from source, and I gave it a Branch Remote Run trigger.
However, it looks like TeamCity only triggers the one project that has the Branch Remote Run trigger applied. I have several unit test projects, set up in a chain with Finish Build triggers, and none of these get run. Furthermore, if I try to start a custom build of one of these unit test projects, I can't use the artifacts from my personal build: I can only pick artifacts from one of the 'official' builds.
Can I get TeamCity personal builds to work with build chains?
With the setup that you have (snapshot dependencies and finish build triggers), you can achieve build chaining by submitted your personal changes to the builds you are looking to trigger. For example, if you have projects A and B where B depends on A - run the remote build against project B and A will be triggered first and B will be added to the queue. Both of these builds will have your personal changes.
If you are using the TeamCity Visual Studio plugin you can select which builds you want to send your changes to and you just need to tick the box for B instead of A.
The finished build trigger won't be fired, but the build chaining means that A must be built first.
More info - http://confluence.jetbrains.net/display/TCD7/Build+Chain
(You have tagged TeamCity 6.5, but 7 has now been released so I have included the documentation for the newer version)
I suppose you should setup your chain not with Finish Build trigger, but with "Snapshot dependencies" feature of TeamCity. And, setup artifacts dependency basing on the snapshots.
Please read about snapshot dependencies in TeamCity here.
I'm trying to setup my VisualStudio project to set the assembly version based on the latest subversion revision number as described on this page. But the version number always seems to lag one revision.
I've split out the assembly version attribute into a separate file, VersionInfo.cs, that is updated with a pre build event.
I'm using the following code to display the version number in the title of my form:
System.Reflection.Assembly assem = System.Reflection.Assembly.GetExecutingAssembly();
this.Text = "My Program Version: " + assem.GetName().Version.ToString();
Here's an walk through of what's happening.
I commit my project so that it is at the latest revision.
Using TortiseSVN I use show log to see that I'm at revision 55
I build my solution.
I then open VersionInfo.cs and see that the pre-build event correctly overwrote this file as
[assembly: System.Reflection.AssemblyVersion("0.1.55.*")]
Yet when I run the program the title bar displays and old version 0.1.52.20486
Next I open the project file in notepad, and change something, such as adding a blank line, and then save the file.
VisualStudio shows a notification that the project file has changed and prompts me to reload the project which I accept
Now when I build and run the program the form shows version 0.1.55.20645
I make a change to something in the project, and commit to SubVersion.
TortiseSVN confirms my working copy is now at revision 56.
I build my project and VersionInfo.cs is correctly updated to
[assembly: System.Reflection.AssemblyVersion("0.1.56.*")]
I try running the application again and the forms title shows 0.1.55.20750 rather then 0.1.56.xxxxxx
Also I've noticed that even if I rebuild/rerun my application the build number (the last number in the version number) is also not updated. It was my understanding that the asterisk would be replaced my a new number at each build.
Any one have any idea what's going on?
I haven't worked with the specific tool you are using but the tool I am using requires you to do an update on your sandbox after your commit. Has something to do with the tool using the revision number retrieved by the last update, not the last commit.
When you checkin a file, the revision number is incremented as you know. The problem is, you do not know what that revision number will be when you checkin - you only find out after checkin.
So, if you take the latest revision number, build your project, then checkin - the number used will always be out of date. What you really want is to be able to checkin, then get the revnum of the commit you've just performed, and then build your project with the correct version number.
Obviously this is not possible.
There is a way round it - use a CI system that builds your project immediately after checkin (through a post-commit hook). These will checkout the latest version you've just added, update your version.cs file, then build. The disadvantage is that your version.cs file will never contain the correct version number (unless the CI system then checks just it in again)
The best way to handle this is when you do your build.
I use Jenkins as my continuous build server instead of relying on doing a manual build on my system. If you don't use something like Jenkins (Hudson, Atlassian Bamboo and CruiseControl are three other popular Continuous Build servers), you should. This way, your official builds are not dependent upon a particular developer machine.
If you do use Jenkins, you can now use Nant or even Ant to help you manipulate your build. We are doing this now with Jenkins and Ant.
What I do is use msbuild.exe to build my project using Jenkins. Before I do a build, I use Ant to retrieve the Subversion revision number (actually, we use Jenkin's build number, but the theory is the same) to modify the assembly file with the correct version. Then, I do a build itself. The results is the correct Subversion revision number (err.. in our case the Jenkins Build Number) in the assembly file when it's built.
Come to think of it, you can probably do what you're doing now to set the Revision in the Assembly file. Jenkins will then build the project with the correct Revision number in the assembly file. You download the built package, and you'll see the correct version number in the title bar.