We have set up the “develop” branch in our git repository as default branch and selected this “Single branch” as “Branches to Monitor” with the “Branch Name” “develop”. If now someone commits something to the develop branch everything works as expected and the build trigger creates a release based on the develop branch.
When now someone commits something new to a different branch and the quick build starts (manually), not the configured “develop” branch will be build but the branch where the latest commit happened.
We have just tested this scenario, and unfortunately we do not see the same issue. Which version of Continua CI are you using?
Where are you seeing the wrong branch - is it listed on the Changes tab for the build or is the issue that you are seeing the wrong files in the build output? If you look on the Changes tab for the configuration, can you see more than one branch listed there? Also, can you check whether any branch mappings are set up for the repository in the configuration wizard?
Hi Dave, we use the latest continua version 220.127.116.118 and we see the wrong files in the build output. No Mapping is configured in the Repository. I made screenshot from the Continua Build Changes page and from the history of the git repository
I tried to reproduce The problem with another configuration and another Git Repository but here the selected branch was correct.
Please find also attached an export of the configuration where the problem occurred:
ContinuaCI Export of ‘Vicos OC 100 TTP’ 2021-08-04.zip (2.6 KB)
From your screenshots, it looks like the built changeset is one that has been merged from a feature branch into the “develop” branch. This is now part of the “develop” branch and is therefore picked up by Continua CI as a changeset on the “develop” branch.
So this appears to us to be correct behaviour. Are you wishing to exclude merge commits from the repository?
this was not a merge from a feature branch to the develop branch but a “cherry pick” from the develop branch into a patch branch. The commit messages in the screenshot are misleading, they were set automatically by the “Git Extensions” client. After the “cherry pick”, the patch branch was the one that was chosen when the fast build “>>” function was used to build the configuration. After someone merged into the develop branch, the behavior changed back to the expected and the develop branch was build when startet with “>>”.
From your first screenshot, it appears that Continua CI has picked up commit
80b160ec as being on the “develop” branch and it is currently listed in the database against this branch. It’s therefore not the
>> quick start build that is the issue - you would get the same result if you used the queue options dialog.
On each repository check, Continua runs “git fetch” and uses the output to determine which new commit ranges are on each branch. For single branch repositories, all other branches are filtered out before saving the changesets to the database. The Changes tab on the configuration view shows a list of all the changesets detected by the associated repositories and the branch they are associated with.
Perhaps something different is happening with the cherry picked commit, causing it to be detected as a new changeset on the “develop” branch. We’ll set up some tests to see it we can reproduce this.
Can you run the command
git log develop --graph --decorate --source --topo-order --parents --cherry-mark > gitlog.txt on your repository working folder? Use the
-n option to limit to a relevant number of commits. If you send the output to me via direct message, this may help us to understand what is causing this issue.
Thank you for sending the git log output. We’ve spent a lot of time testing a simple branch git repository today - this included cherry picking normal commits and merge commits, with and without tags, to a feature branch. Unfortunately, we could not reproduce an issue where a commit from the feature branch was picked up and associated with the incorrect branch in Continua CI.
If you are able to reproduce this issue with a test repository with debug logging enabled or set out the steps (a set of git commands) to reproduce the issue, then we will be able to investigate further.