This is not neccesarily a bug report, but anyway here goes.
How should branches in container directories be defined for branch aware SVN repository?
We currently have branch pattern branches/[Container1|Container2]/[^/]+ indicating that we have branch directories in two separate container directories under branches:
branches/
- Container1/
– branch1
– branch2
– 2012.2
- Container2/
– branch1
– branch2
It appears that Continua is able to get sources from these branches to the server disk.
However it would appear that changes to these branches are not detected automatically repository change trigger.
Also when manually starting a build, the branch entry field offers only the trunk as auto complete option, and nothing else. When entering manually the branch the build ends in an error:
Build Error Agent workspace failed to initialise in the specifed time : Running C:\Program Files\VSoft Technologies\ContinuaCI Agent\hg\hg.exe failed with return code -1 and error output abort: unknown revision ‘9c9c2f499a2e49fa2c7bc46faed7b159b3a40367’! (Args were : archive -r 9c9c2f499a2e49fa2c7bc46faed7b159b3a40367 -I “re:^((branches(\|/)Container1(\|/)2012.2.*))$” -R C:\ContinuaAgent\Repos\a1d34519 C:\ContinuaAgent\Ws\1058\Source\TestAutomationFramework --config ui.username=Continua)
Is there now something wrong with our setup, or how we use the system, or something wrong with the Continua?
The Agent workspace error is a bug we are working on at the moment. We identified a situation where the build can get to the agent before the agent has the revision in it’s cache, due to a bug in the server code. We’re reworking the code that handles change detection and the updating of the cache to be more synchronous, the previous implementation was message based, and we found some cases where things could happen out of order. We got the new implementation working yesterday, but all the repository implementations need to be reviewed and re-tested. I hope to have a new build ready for testing by the end of the week.
As for the triggers not firing, we’ll check this out, I suspect it has to do with the branch name matching. What do the changesets show the branch names as?
As for knowing which branches it will detect, that may be difficult since svn doesn’t report the branches like other version control systems do. What we may be able to do is add a regex tester to the field which might help get the pattern right.
When specifying the branch, you need to specify the full branch path, so :
branches/Container1/2012.2
You should get intellisense for this in the branch field on the start dialog (assuming a changeset for the branch has been detected). We spent today working on this repo type, the build you have has some issues with the branch name it detects, especially if you use svn < 1.7
We spent today working on this repo implementation, it should be much improved in the next build, and we’ll update the doco to show more examples.
Maybe by late tomorrow or Friday barring any issues cropping up. We’re reworking the last 3 repo types at the moment, they all had to be reviewed and modified to work with the new way of managing the repo cache.
We have tested now with the current build (1250), but the branches still won’t build. When trying to manually start a build from a branch the build initialization fails with error “No changeset associated with build for repository”.
Sorry we missed your reply from a few days ago. Is continua detecting any changes for the branches? If you commit a new change in a branch does continua show the change on the configuration\changes tab? I’ll take another run at this when we get back after the break (Jan 2nd).
We have been able to reproduce this here, we should have a new build with the fix available shortly. You will need to delete and recreate your repository to ensure we detect the changesets properly.
Our installation was upgraded to the most recent beta (1.0.0.1291), but we’re still unable to trigger manual build from a branch. The build attempt fails with error “No changeset associated with build for repository: TestAutomationFramework”.
I did recreate the repository for the project as suggested in the release notes for build 1281 before this.
Same issue is still present with the newest beta. Is there any resolution for this - it’s not feasible to have a change for every branch for continua to be able to build it.
Are you able to create a new Continua repository pointing to the same svn repo? I’m wondering if it’s a state issue. Also I think it might be beneficial if we setup a web meeting so we can see exactly what is happening, I’ll contact you by email today so we can organise a time.
I think we have found what might be the problem. We setup a repository with the same structure as yours and the (bad) regex I gave you and discovered the problem was that the regex didn’t match. This regex will work :
I think the main take away from this is we need a better way to test the patterns against what would typically be spat out by the svn log command. In this case what caught us out was the forward slash at the start of the path reported by svn log.
I think we need to add some debugging output to see what is going on. The error you are seeing is because the continua repo has not detected at least 1 commit in the branch you are trying to use. On the configuration view, if you switch to the Changes tab, does it list any changes there at all? It may well be worth recreating the repo in continua.
We’re in the middle of doing some refactoring of the subversion repo code at the moment to enable better code reuse between the normal and the branch aware repo (they were written by different devs), and to enable proper support for svn externals. We should be done with that in a day or so, we’ll get the debug code in as part of this refactoring.
It would help if you showed us exactly what settings you have on your repo, and the tree structure of your svn repo. We have tried to duplicate it here based on the info provided in this thread, and it’s working fine, so I can’t help thinking we’re missing something that might help us diagnose or reproduce the problem. Feel free to contact support@finalbuilder.com with the info if it’s stuff you don’t want in public.