We have configured a VCS per project defining "branch specification" and a "default branch" like shown on the image below.
There is no new commit on the default branch in Bitbucket (our VCS) since the last successful build. Nevertheless pending changes appear on TeamCity when selecting the "default branch". These pending changes are commits from another branch.
Do you know what could be the issue ?
For information, we use TeamCity Professional version 10.0.4 (build 42538).
Related
With sonarqube running on my project, I created a new branch other than main, as the default one and started working on the same. While running sonar, only the main(master) branch is taken into consideration by default. I tried this short-lived branch feature, but it compares the files with master branch and shows only the files which are modified in the new branch. The files which are created in the new branch are not shown. How to fix that ? or how to change the default branch in sonar.
Sonar : Community Edition : version 7.9
If you are asking about the default branch in SonarQube, the community edition is seen to be showing all the projects as with 'master' branch.
Could refer https://docs.sonarqube.org/latest/branches/overview/
Master / Main Branch This is the default branch and typically
corresponds to what's being developed for your next release. This is
usually known within a development team as "master" or "head" and is
analyzed when no specific branch parameters are provided. It is
labeled "Main Branch" and defaults to the name "master" but can be
renamed from the project settings at Administration > Branches and
Pull Requests. When you are using Community Edition, this is the
only branch you see.
With community edition, I found a fix. Provide the value to sonar.branch.name to the intended branch. In my case sonar.branch.name=sprint7_bugfixes. The sonar will run for whole of the branch and will update the content in dashboard, but still the name will be shown as master.
Another way of doing that is changing the project key and project name along with branch name.
I would like to create an integration build in VS Team Services, that is triggered when a commit is done to any branch (develop/feature xy) except master.
I am able to create a trigger for this:
but how do i checkout the sources of the branch that triggered the build?
In the task tab, the first step is 'Get Sources' and here i'm only able to choose one branch (the * wildcard is not possible here):
Otherwise for example a build is triggered by a feature branch, but the sources are taken from the develop branch. How can i do this?
You filter is perfectly fine if you want to build anything but master branch.
The branch you select in build definition is just the default branch used when you Queue New Build manually.
OTOH the build trigger establish which branch to download, e.g. if the build has been triggered by a git push on branch develop then that is the one checkout'ed and built.
When you queue a new build manually, you also have the chance to change the default value to whatever branch you would like to build.
We're using teamcity with github enterprise. And we have it set to run on merge requests as well as commits. However, git keeps sending teamcity commit messages for merges that have 0 file changes, which triggers a build.
For example, this will trigger a build:
I've found the documentation here for creating a trigger filter
But I don't see a way to create a filter on the number of updated files.
I think this is what's causing the builds
Triggering a Build on Branch Merge
The VCS trigger is fully aware of branches and will trigger a build once a check-in is detected in a branch.
When changes are merged / fast-forwarded from one branch to another, strictly speaking there are no actual changes in the code. By default, the VCS trigger behaves in the following way:
- When merging/fast forwarding of two non-default branches: the changes
in a build are calculated with regard to previous builds in the same
branch, so if there is a build on same commit in a different branch,
the trigger will start a build in another branch pointing to the same
commit.
- If the default branch is one of the branches in the
merging/fast-forwarding, the changes are always calculated against
the default branch, if there is a build on same revision in the
default branch, TeamCity will not run a new build on the same
revision.
It's worth noting, that builds on branches that haven't been updated will be triggered by a merge in another branch.
You probably use checkout rules. Otherwise, running a build on a merge commit with 0 files seems an appropriate action: the commit does change the content of the checkout directory and should trigger a build.
If you limit what you checkout via TeamCity checkout rules, TeamCity only displays the merge commit with 0 files if it actually changes the content of the checked out directories (by merging files in the directory), or the commit graph is not fully known to TeamCity, and it potentially can affect the checkout.
If you are not running the latest TeamCity release (10.0.5 as of now), it makes sense to update. If you still get merge commits displayed which are not affecting the checked out files and are not merging commits created before the VCS was configured in TeamCity, it makes sense to report the details to TeamCity support.
I am having a bit of trouble with the Branch Updater feature of Bamboo.
If a new commit is pushed on a branch that is using the branch updater, Bamboo checks if there are new commits on the dependent branch(in my case the master branch) and if this is the case it merges the changes and runs the build.
However, if this build fails, it is hard to recognize, if the new code on the branch itself is broken or if it just could not be merged correctly with the master. Therefore I would like that in these cases the branch is build independently first and only if this build is successful, the changes on the master are merged in and the branch is build again.
Is this possible using the branch updater feature?
A workaround might be to use multiple build plans and use one to build all branches isolated and another plan to integrate everything using the branch updater.
The "Branch Updater" feature is to merge the code from master branch into feature branch after a successful build of the master branch.
However, currently there is NO straight forward option in Bamboo (except the workaround mentioned in your OP) to build the branch and auto merge only if the branch build is successful.
Typically, the developer runs the build in local and commit the changes to repository if the local build is successful. There are two things that can go wrong.
1) While running the local build, the latest code from feature branch is not available in local. Some of the repos like GIT would complain if the local doesn't match with HEAD revision, you need to update to HEAD before you commit the changes. In this case, you can run the build again to ensure there is no problem.
2) When the master code merges with feature branch, something could go wrong
I understand that still there is a gap which can be addressed to resolve the point 2.
You can create a ticket in Bamboo with detailed explanation of the use case to add this feature.
What needs to be configured in TeamCity 7.1 that it triggers a build only when a commit happens to a master branch in git?
Currently, it triggers when changes to other (feature) branches are pushed to the remote repository.
Huh, seems like we had a service hook attached to TeamCity at GitHub, it was triggering those builds.
After turning off Github hook, build now it works as expected, builds only when pushed to master.
(Alternatively, hook can be configured to filter by branches)