I am using Teamcity to build docker builds and I want to use the git branch in build steps. I create a build within a project, I then create a build step in that build to do a docker push and I set the image name:tag to registry:5000/myproject/%maven.project.artifactId%:%teamcity.build.branch%
When I run the build, it just queues and nothing happens. There is a message saying:
Implicit requirements: teamcity.build.branch defined in Build step: Docker push
How can I get the git branch so that I can use the branch name in the docker label:tag?
Related
good day. i try to ask same question on teamcity support forum but with no luck, so i try to find solution here
i have 4 (actual more, but other configuration not important for the situation):
'verify' - configuration that run test, check that all migration can be applied to database (run in docker) etc. this configuration triggered by gitlab (integration with teamcity feature)
'build' - configuration that build all application components and push docker images to hub
'deploy to test' - use corresponded artifacts from 'build' configuration and perform deploy images to test server
'deploy to staging' - same as 'deploy to test' but use staging server
'deploy to production' - same as 'deploy to production' but use production server
we have several stream in out repository with corresponded rules:
develop
feature/* - feature task that should be build then corresponded merge request to develop was initiated. merged to develop
release/* - release that should be deployed to staging server at each commit. merged to develop and master
hotfix/* - hotfix that should be deployed to staging server at each commit. merged into develop and master
master - stable branch, should be deployed to production on commit.
so, i create following VCS root:
default branch: refs/heads/develop
branch specification:
+:refs/heads/(*)
+:refs/heads/master
+:refs/heads/release/*
+:refs/heads/feature/*
+:refs/heads/hotfix/*
+:refs/(merge-requests/*)
after that i setup branch filters (for VCS Trigger) for each branch configuration:
verify - none
build:
+:refs/heads/release/*
+:refs/heads/hotfix/*
+:refs/heads/develop
+:refs/heads/master
deploy to staging:
+:refs/heads/master
+:refs/heads/release/*
+:refs/heads/hotfix/*
deploy to test:
+:refs/heads/develop
deploy to production:
+:refs/heads/master
so this is my setup, now my problems:
then gitlab trigger teamcity (on merge request) the verify configuration started. but i see following message (for example):
The build was triggered in the branch feature/VTS-610 which does not correspond to any branch monitored by the build VCS roots (the branch is either closed or excluded / not matched by any branch specification). Because of that default branch revisions were set to this build.
same message i can see if merge request initiated for hotfix branch (of course with another branch name, ie hotfix/VTS-654).
after hotfix branch merged (we create two merge-request: one to master and one to develop), i can see that deploy to staging was triggered, but deploy to test does not.
I had the same problem, the root cause in my case was the predefined build parameter teamcity.build.branch (see Build Branch Parameters)
The parameter was set in the build configuration of the failing build under "Parameters / Configuration Parameters". As I had no use for this parameter anymore, it was safe to just delete it. I was then able to run the build configuration with any branch that is accepted in the Branch Filter under Version Control Settings.
I have a TeamCity project :
Commit build
Another build
I want that if my commit build is successful on a generic branch name (if the branch name contains a specific word), another build start. The specific word is toto-ok in the example.
Example:
commit build on develop: do nothing more
commit build on branch feature/blabla-toto-ok-blabla: trigger
the other build
commit build on branch feature/something-else: do nothing more
commit build on branch feature/something-toto-ok-else:
trigger the other build
Given I have Teamcity job with Git VCS root with default branch which can be changed with branch-name parameter:
When I e.g. set branch-name to develop in admin screen, go back to build configuration home and run custom build where I change branch-name parameter to master
then I get:
Why is that?
What should I change, so that I don't get this message and I can change branch when running custom build?
The reason for this is I want to build and deploy software artifacts from any feature branch
the Teamcity has an opportunity for monitoring the branches and runs built to custom branch.
Firstly, edit your VCS Root and add follows:
Default branch: refs/heads/master
Branch specification:+:refs/heads/*
now the TC will check changes by some interval.
We are sets the master as default branch. and when we run the build with default parameters, the build will start to master branch
If you are want to start build with custom branch then press Run... -> Changes -> select your custom branch from Build Branch parameter.
If you want to run build from API, or want to reverse the build branch parameter, just set Configuration parameters with key teamcity.build.branch
and value what you want
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events
I am trying to get TeamCity to clear out the publish directory on a remote server AFTER a successful build on the build server. I want this to work like a clean checkout does on the build server. The workflow should be:
Checkout
Build
Clear Publish Directory
Publish successful build files to Publish Directory
In TeamCity 8.x, workflows like this can be done using the conditional-execute option on build steps within a config. Your "Clear Publish Directory" build step could set the "Execute step:" option to "If all previous steps finished successfully (zero exit code)". And similarly for build step 4.