My build configuration pulls code from multiple vcs roots. As part of my build process I build an open source project from github, which unfortunately has just introduced a dependency that breaks the build on my server.
Is there any way I can change the specification of the VCS root to limit it to the commit before the dependency was introduced? I don't want to manually run a specific commit as this would force the other repository in the build back to the same point in time, which would mean I'm never building my latest code. For reasons outside of the scope of this question, I need to build all projects from source, so can't take a pre-compiled version.
Is it possible to force teamciy to always check out the same commit of a VCS root?
Most of projects are using tags to identify versions so probably you can use it.
Or if you always need only one version you can fork repo and add branch/tack on your copy
Unfortunately git refspec does not provide possibility to specify commit by hash.
Related
We use gradle and have our Version-Number stored in gradle.properties.
Further we use "SNAPSHOTS" to identify builds from develop.
When creating a new release we remove the SNAPSHOT Postfix in develop, create a Release Branch and increase the Version-Number to the next SNAPSHOT Version in develop.
This process prevents merge conflicts for the gradle.properties, when finishing the release branch (which merges the last changes from release to develop branch).
But now we have the problem, that we have merge-conflicts (or worse fast-forward merges!) when creating hotfix-branches from master and merging them to open release branches and develop.
The same problem occurs with Maven Projects, where the Version-Number is located in the pom.xml.
Is there another good solution to prevent this problem? I was thinking about externalising the version-number and passing it e.g. via Build Parameter or store it in a file which is not under version control but this has the disadvantage, that you can't identify the version from the source.
Any help would be appreciate.
UPDATE
Another Idea is it, to use the Branch- / Tagname to identify the Release-Number.
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 am thinking about a deployment pipeline using SVN, Jenkins and Maven. At the moment I'm stuck at the point where I usually would call mvn release:perform on a working copy.
When thinking in deployment pipelines, I want to create a pipeline where every commit could be used to release a software to test/production. Let's say I have 5 builds, and I decide to release build 3 (with revision 3) to production. There will already be 2 new commits to trunk (which is now at revision 5).
Is it possible to use the maven-release-plugin to checkout/build/tag/commit a release at revision 3? When the maven-release-plugin finishes the release it usually commits the modified POMs to trunk.
I'm happy about any kind of information or advice here, so feel free to point me to books (like http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912), blog posts, Jenkins documentation... Maybe I'm completely on the wrong track.
By default, the release plugin creates the release based on the contents of your working copy, it just ensures that you don't have any uncommitted content before doing so. AFAIK it doesn't force an update of the sources, as that's usually the job of the Continuous Integration system (Jenkins in your case). So whatever is checked out by Jenkins will be released.
What you're trying to do sounds more like a configuration change on the Jenkins side, pointing it to the right revision.
On the other hand, if the POM files are modified as part of the release, but have been changed in SVN in the meantime, you will run into a conflict when Maven wants to check in the modified POM files. That's a situation that might happen, depending on how for back you want to go with the release.
Based on this, it might make more sense to always create a branch before doing a release. So you would create a branch based on revision 3 and then create your release in that branch. This way, you wouldn't run into issues with committing resources that have changed in more recent revisions.
Creating the branch and checking it out could probably be automated through Jenkins and Maven as well.
As far as I tested it, it is not possible.
More explicitely, as nwinler said, when you release, maven try to commit the modified pom. But, if it's an older revision than the current one, SVN will complain that your sources are not up to date. So it won't work. ... as far as I know.
You may read docs about promotion build. I don't find any one clear enough to be pointed out (in th few minutes of the writing of this message).
I've got a CI build pulling feature branches from Github and building/packaging them into a local folder, using a folder naming convention based on the project, branch and build number.
For named branches (feature1, feature2) this is working great.
The problem is that when I do a commit to the master, TeamCity exposes teamcity.build.branch as <default> - which means when the build step expands
E:\Packages\MyProject\%teamcity.build.branch%\
it's ending up with E:\Packages\MyProject\<default> - which is then crashing the build step because it isn't a valid Windows path.
I can see the master branch name in the fully-qualified build parameter:
teamcity.build.branch <default>
teamcity.build.checkoutDir C:\TeamCity\BuildAgents\agent-mulder\work\2151838a7933464d
teamcity.build.default.checkoutDir 2151838a7933464d
teamcity.build.id 16347
teamcity.build.vcs.branch.github_myproject refs/heads/master
but ideally I need to get master as the teamcity.build.branch for use in my build steps.
Can I transform the parameter at runtime? Override the behaviour? I've even tried setting the VCS branch name to DO_NOT_USE in the hope that "master" would no longer match the default - but this doesn't appear to work either.
In teamcity 7 its simply %vcsroot.branch%
that returns develop.
In my case I have
%MajorVersion%.%MinorVersion%.%PatchVersion%-%vcsroot.branch%
Which are all set in build parameters.
The number format is %BuildFormatSemVer% which is the stuff above and . {0}
%BuildFormatSemVer%.{0}
Which returns
#1.0.0-develop.4
Not ideal, but I was able to work around it by creating a new branch in git named "teamcity" and setting that as the default branch in TeamCity, it seems to require that the branch actually exist, since it worked when I created the branch, but didn't when you just entered a fake name.
Hopefully they actually fix this, because this is definitely a hack.
We have run into this problem several times when creating pipelines. It is the most visible when trying to automatically build feature and release branches using the Gitflow workflow. What we've been able to do was to use teamcity.build.vcs.branch.github_myproject and a regular expression in sed to sanitize the string whenever we wish to use it. This is mainly to watermark artifacts for debugging purposes.
The larger issue, at least for us, is that the TeamCity 7.1.1 version does not automatically fire off dependency builds for anything that isn't the default build in the VCS root. Obviously this is a huge pain point as we're now going to have to click manually in the tool. We haven't yet figured out a clean way to get around this other than hooks in git which use the HTTP API to call out to the proper build step.
I don't know if this was previously answered, or is any longer relevant.
In TeamCity 10.0.2 create a custom parameter such as %Git.Reference%. If you require a pull (or push) from TC to git, set this to "ref/head/Dev" or "ref/Head/yourbranch". Use this in your 'VCS root' reference.
So far, I've only used TeamCity as a continuous build server. No true integration. Now, I have the need to copy the output from one shared project to two other dependent projects, and kick off their automated builds in turn. That is, ProjectA and ProjectB both depend on ProjectC. All three are currently being built by TC when any commit occurs in their respective repositories. What we desire, is for the output of ProjectC to be copied and committed to ProjectA and ProjectB. Such a commit would in turn start the build process of both dependent projects. This seems like it would be a common scenario when talking about continuous integration. Is it not?
To clarify, we're using TeamCity v.4.5.5 (build 9103), SVN, and nAnt as our build runner.
EDIT: I mispoke when I said something about committing to another repository. They actually all three reside in the same physical repository, just at different levels in the hierarchy.
I don't know whether TeamCity supports this, but this should be easy to script by yourself - as a last step of build in ProjectC add a script that will checkout ProjectC directories (not whole repository, just a directory where you keep binaries of ProjectC) from ProjectA and ProjectB, copy all required files and commit with some autogenerated message - seems quite simple.
However - this is dangerous. Build of ProjectA and ProjectB could break because an API of ProjectC changed, or some untested part of code was broken. This could disorganize work of teams A and B. I would go for solution where new version of libraries are commited once a day / a week / any other time period.
Also, it might be a good idea to create an automated changelog - for example, if you trust quality of your svn log messages, you could create a changelog from all "new" commits included in commited release (or append current log message, if you decide to choose to push new libraries after every commit). This way teams responsible for ProjectA and ProjectB will be able to easily fix their build if new library breaks it - they'll know exacty what was changed, without need to check manually/ask team C.
Typically you don't commit build output to your repositories. Are you sure that's what you want?
You can make TeamCity copy the output (artifacts) from one build project into directories of another, but in order to commit it, you'll need to add some scripting, like a batch file or similar.
In newer versions of TeamCity you can define artifact dependencies, this will allow you to create a "library" as per your example and pull the artifacts of that build into your other projects. If you are using something like Node.js/npm to build a project, you will want to capture the output folder as well (e.g. 'dist') so that when you restore the artifacts you can unpack a single folder instead of a list of dependencies.
I can expand on this example if anyone is interested, just wanted to let folks finding this via Google that it is much easier to do now.