16

Can TeamCity push successful builds to a git repository?

I cannot see a specific build step in TeamCity to do this.
I use the version 7.1.1 of TeamCity

Thanks, Henrik

UPDATE:

Ok thanks for your answer, I find it a bit complicated. I found out that I can simply push back tags on successful builds to my global repository from which TeamCity fetches data for the build. I can pull changes from it and see whether the last commits were successful.

I would be happy if TeamCity provided a simple option for this kind of workflow!

It would be awesome if every developer could just pull from a repo that is only updated when the build is successful, or am I wrong here?

Mark Pearl
  • 7,573
  • 10
  • 47
  • 57
Henrik
  • 289
  • 1
  • 3
  • 10

5 Answers5

6

You can have TeamCity execute a shell script that subsequently calls git push (with appropriate arguments, e.g. git push <repository> to push to a different repository). Do make sure that git doesn't need interactive authentication for the push operation.

A related example (deploy to Heroku using a git push) can be found here: http://blog.carbonfive.com/2010/08/06/deploying-to-heroku-from-teamcity/.

praseodym
  • 2,134
  • 15
  • 29
  • You can simply call `git push` with the appropriate arguments to push to an entirely different repo. – praseodym Nov 10 '12 at 22:37
  • Ok I see... I added another build step type "command line" and choosed custom script which contains: git push C:\TestAppRepo but this will not work any idea??? – Henrik Nov 10 '12 at 23:02
  • The call to `git` in the Windows batch file will probably not return; try using `call git push …` (i.e. with the `call` keyword) instead. – praseodym Nov 10 '12 at 23:04
  • Does it work when you manually execute it in a command prompt, and when it is executed by TeamCity what error is logged there? – praseodym Nov 10 '12 at 23:15
  • thanks for your help, my teamcity logs: [00:09:58]Step 3/3: Command Line [00:09:58][Step 3/3] Step Command Line failed – Henrik Nov 11 '12 at 11:40
  • Hm, this is turning into a bit of a chat… Could you enable a higher logging level in TeamCity? Debugging an error without more information is nearly impossible. – praseodym Nov 11 '12 at 20:26
  • Note that VCS checkout mode='Automatically on server' does not work as there is no .git directory. Adding `pushd %teamcity.build.checkoutDir%` and `popd` before and after the body of the script may also be necessary (i.e. with shared repos) – karmakaze Oct 25 '13 at 20:27
  • @karmakaze - I've [looked up what `pushd` and `popd` do](https://en.wikipedia.org/wiki/Pushd_and_popd), but could you explain why they're needed for this? Or point me to more information? – Justin Morgan - On strike Aug 25 '16 at 15:01
  • @JustinMorgan If I recall, the idea is to `cd `, do whichever git commands you wish (git tag, git push, etc), then return to the original dir, thus `pushd` to cd and remember starting dir and `popd` to return to the starting dir. – karmakaze Sep 01 '16 at 05:24
6

i finally made it!

You have to add a build parameter in your teamcity project:

name= env.PATH
value= C:\Program Files (x86)\Git\cmd

and then you add a new commandline build step with custom script:

call git push "C:\Gruene Git Repos\TeamCityApp" master

the "call" word is important!

Thanks for the help! henrik

Jono
  • 3,949
  • 4
  • 28
  • 48
Henrik
  • 289
  • 1
  • 3
  • 10
  • this was more or less correct, i added `"C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin;"` to the system PATH environment variable. setting the path variable with TeamCity will override the system path variable and dependent exe's could not be found anymore. – SeriousM Apr 02 '13 at 17:29
  • 1
    I tried setting up the checkout directory to a custom path, and it checks out to that folder, but the folder isn't declared as a git repo, it's just a copy of the HEAD version checked out. How do I gain access to the repo folder? – amhed Mar 27 '14 at 14:26
  • 1
    For future reference, the checkout mode needs to be set to: "Automatically on agent". The option is under the advance section of VCS settings for the build configuration. This ensures that the build agent has a full git repository. – Mark Lopez Feb 28 '16 at 21:23
5

If you upgrade to 8 or newer you can just make one or more "Automatic Merge" build features. This will push to remote repo. I didn't find it at first either because of the confusing naming but it makes sense that they have to support many different VCS with different naming.

Esben Skov Pedersen
  • 4,437
  • 2
  • 32
  • 46
  • Do you have a working example of using Automatic Merge? I have it enabled in a build, but nothing happens. I'm pulling from any branch, and trying to push to master. – Stealth Rabbi Jun 23 '16 at 19:32
  • Yes i got it working at some point but we stopped using it since it was not powerful enough for our use cases. – Esben Skov Pedersen Jun 23 '16 at 19:36
  • 1
    OK, can you provide the example though? I'm trying to use this feature, but I have indication in the logs that ti's even attempting to run. – Stealth Rabbi Jun 24 '16 at 13:45
  • Im sorry i dont have access to that system any more – Esben Skov Pedersen Jun 28 '16 at 19:16
  • 3
    Automatic Merge doesn't do this. Based on the documentation and my own build logs, [it only supports merging, not pushing](https://blog.jetbrains.com/teamcity/2013/10/automatic-merge/). If there's a way to get it to push, I'll gladly remove the downvote, but the statement `you can just make one or more "Automatic Merge" build features` implies it does that out of the box with no fancy setup, which isn't accurate. – Justin Morgan - On strike Sep 06 '16 at 15:09
2

Easy Answer

For a while TeamCity has supported VCS Labeling, this allows your VCS Root user (if it has write permissions) to tag the commit hash that was just built with the version or anything else TeamCity knows about (see entire list of parameter references in the TeamCity wiki).

An aside

As stated in another answer the Automatic Merge functionality available in TeamCity will automatically perform a merge into a requested branch from the specified list of branches (wildcard enabled) and it will monitor and build and only merge them if it succeeds.

The Automatic Merge functionality can be good, but if you don't have good test coverage it can also be dangerous as a developer could break something that doesn't have a test and that will cause issues in your code long down the road. One way to prevent this is to require +2 tests be created/run every time the project builds (configurable in TeamCity). These caveats are mentioned in the previously linked article announcing the Automatic Merge feature.

Related Resolution

We encountered a similar issue not related directly to merging, but having a requirement to push some changes from the job beyond the "lightweight tags" (for Git at least) that TeamCity adds if you use VCS Labeling (terrible name).

What we ended up doing was:

  1. Using a Parameter of the type "Environment Variable" (visible to the build agent, the other types are not) and setting the "Spec" to make the field of type "Password" which will prevent the entered text from showing in either the config UI or the Job log output.
  2. Entered the username and password as parameters on the job config
  3. Created a script that looked at the git remote URL of the "agent side" repository and added a new remote with the username and password inline in the url (http://gituser:gitpassword@githost.com/path/to/repo.git) in order to push the changes on a new branch.
    • We then remove the remote at the end of the script so that anyone accessing the system can't pull out the credential. Of course the credential is also fairly tightly scoped to only access certain repositories, but the least privilege rule is always good to follow.
Zhaph - Ben Duguid
  • 26,785
  • 5
  • 80
  • 117
dragon788
  • 3,583
  • 1
  • 40
  • 49
0

My solution maybe is stupid, but simple. The steps is as follows:

  1. Cloning your heroku from heroku git repository it will create your heroku app folder.

    heroku git:clone -a {app-name}

  2. Copy the files you need to update to heroku

    xcopy client "{app-name}/client" /e/i/h/y

    xcopy server "{app-name}/server" /e/i/h/y

    xcopy imports "{app-name}/imports" /e/i/h/y

  3. git add.

    cd {app-name} && git add .

  4. git commit

    cd {app-name} && git commit --message 'ok'

  5. push to heroku

    cd {app-name} && git push heroku master

ScottLee
  • 75
  • 1
  • 2
  • 8