I'm trying to figure out how to configure TeamCity build steps to accomplish the following tasks:
Call a console app that merges the dev branch to the test branch (in
TFS) and modifies some of the files manually in the test branch that
are used for the projects configurations. This process works perfect
and has been tested. Also note, this step does not check in the
merged files or modified files to the test branch.
This build step will kick off the actual solution build for the test
branch. (This is C#.NET, but I don't think that is significant)
This build step handles the database migration for any SQL scripts
added. (This step has also been tested and works)
This step calls another console app. This step will run even if a previous steps fail. If the build has been successful it will check in the pending changes from step 1, and do the deployment of the build. If the build has failed in a previous step, it will undo the pending changes from step 1.
That seems simple enough to do, but I the interaction between steps 1 and 2 is what I don't know how to do. If I use server-side checkout for step 2 it will pull the source from the server and not use my changes in step 1. If I user agent-side checkout, my understanding is that it will create a new workspace and pull the source from the server, again not using my changes in step 1.
Is there a way I can make step 2 build with the pending changes created in step 1? The only other option I can think of is to check in the changes after step 1 and rollback the changeset in step 4 if the build fails. In that case though, how would step 4 know the changeset to rollback?
Also I have one smaller question, how can I pass the success of the build as a parameter to step 4? I looked through the built-in parameters but I didn't one for build failure/success?
Thanks!
It would be useful if you could give the VCS name you are using(Git/SVN). I see you question is mainly on 2 main points
If you are using Teamcity build Steps , where in all build steps
are part of a single target you do not have to worry about
interaction between Step 1 and Step 2 . All steps can run in the same
directory . You always retain your working copy status throughout
the sub steps.
The only glitch in teamcity is that you can not run a build/step "only if
a previous step fails". To get around this, you can create a failure
file in any of the previous steps and run the build only if that file
is present. Delete the file at the end of every build just to ensure
that there are no accidental issues in the next build.
So, in short your build steps can (1) checkout a branch, (2) merge another branch into it , (3) run build and db deploy, and then (4) commit your code /rollback your db changes if it fails based on a failure file.
For your second question, each teamcity step knows the success status of the entire build and the previous steps as mentioned here . The only step missing is " run step if any of the previous step failed"
Related
I'd like to fail feature branch builds if they have less test coverage than the last successful build of master
I tried adding a extra failure condition by following the steps here
https://www.jetbrains.com/help/teamcity/build-failure-conditions.html#BuildFailureConditions-AdditionalFailureConditions
But I can't find a way of referencing the last successful build of master
Is there a special tag automatically set to the "default" branch or do we need to add some code to the build step to auto pin / auto tag it?
Could you add a custom build metric and use a build step to only set the metric when the master branch is being run? You could check the branch name in the TeamCity parameter and only set the value for master? Hopefully this will be easier in the future with conditional build steps (unfortunately not available at the time of answer).
I'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
I have a project that needs to execute either three or four build steps depending on the branch in source control. More specifically, if I'm merging in a PR and running the build (for GitHub status notifications) I have one extra build step that is required.
It's that last build step that I need to omit if it's a non-PR branch.
Is there a way to add a build step that checks the trigger and exits the build successfully? Or a way to exclude a build step based on a branch filter?
You can check the condition and modify the step logic inside the build script. See the related ticket and an example of the script.
BTW, It is not a good practice to change the logic of the build inside build script. In this case you no longer "compare" builds in the build configuration: they start to form multiple unrelated sequences. Also the statistics of the builds will be uninformative. The recommended setup is to create several build configurations based on template.
Depending on which type of runner you are launching, but you can, in some cases, add few lines of code to get your current branch name with the property : %teamcity.build.branch%
In my case, I just add this as an extra parameter for powershell scripts and if this is a number, do something, else, do other stuff. ;)
I have a jenkins job that do build and deploy the maven project. The job depends on few parameters that I pass to the job. This job also checks out the code from git repository.
I have 4 branches ( dev, test, release and patch) as the source code of the project.
How can I run the same job with different parameters and different source code of the project.
Example :
- let say we triggered the job to run by passing param1 and param2 to the job and using the dev branch.
taking into consideration that the run from step 1 hasn't completed , how can I trigger the same job by passing param3 and param4 but using test branch this time
I want to do different build from different source branches from the same job in parallel .
Any other suggested design ?
One inherent problem here is that - when you fire another build of the same job, it will overwrite the workspace it is using.
There are two ways of tackling the issue IMO:
Like #bish mentioned in his comment - two separate jobs.
Pass a parameter that will kick off a small script that will checkout the project to a workspace/subdir folder instead of workspace. You can do this in the Add pre-build step -> Execute shell script. Here, you need to ensure that you don't 'wipeout the workspace folder'.
(The Jenkins GIT plugin has an option to checkout the project to a subdirectory, but I couldn't figure out how to trigger that conditionally. So, going by a simple manual intervention here.)
Next, you can choose to give a list of the branches available as shown in one of my earlier answers
Let me know if this helps.
My build project have 3 steps:
-file preparation
-deployment
-functional tests
I have set all the dependencies between them, but I really wish also to hook the deployment step to the functional test, so that if the functional test are running and new code is committed the deployment wait till the functional tests finish.
I know there are the build triggering, the dependencies and the artifact dependencies but each of them doesn't seem good for my case.
The first run a deployment every time the functional test step finish and obviously is not what I want.
The second force the deployment to use the same code as in the functional test instead it should use new freshly committed code and for the third is more or less the same situation.
Where I'm thinking wrong? I'm missing something or there's a shortcut to use to make this working?
You can create 2 build configurations:
"Functional tests" configuration with VCS trigger.
"Deployment" configuration with snapshot dependency on first configuration and also VCS trigger (or other trigger, e.g. Schedule trigger with 'Trigger build only if there are pending changes' option selected).
Files will be deployed only if functional tests not failed on same code base.
It is what you need?