Hi Olli,
Thanks for the feedback.
On changing repository URL: we’re still discussing what the best behaviour here is. When you change the URL, you’re essentially changing what the repository is, so we need to go off and invalidate all the caches, and potentially update the Changesets we store for that repository.
Repository initialization occurs asynchronously, and any errors should be added to the Event Log. When a repository has an Event Log error associated with it, it should appear with a ‘warning’ symbol on the Administration -> Repositories page. You can also set up a subscription to ‘New Event Log Message’ so that you get an email/XMPP/private message whenever a new event is logged.
Any errors that occur on the Agent should be getting logged to the server’s event log (so long as the agent can still communicate with the server) - you shouldn’t have to rely on the diagnostics app.
We checked in a change yesterday to show the version of each agent, and an indicator that shows if the agent is compatible with the current server version.
We’ll fix the typo, Copy File and Event Log issues - thanks for reporting them.
Cheers,
Ben
The repository typo and event log issues have now been fixed.
Posted By Ben Hughes on 28 May 2012 06:47 PM
Any errors that occur on the Agent should be getting logged to the server's event log (so long as the agent can still communicate with the server) - you shouldn't have to rely on the diagnostics app.
I didn't see at least as detailed error at the server for the current workspace initialization failure.
Did you take a look at the report (at another topic here), and do you have any workaround/fix?
OK, I’ll take a look - we may be logging a truncated message or it may be getting buried somewhere.
Paul is having a look at the workspace init problem. For some reason the agent isn’t being told which SVN branch the build needs, he’s still looking why. Hopefully he’ll have something for you today.
Cheers,
Ben
Posted By Ben Hughes on 29 May 2012 06:55 PM
For some reason the agent isn't being told which SVN branch the build needs, he's still looking why.
Thinking this raised a question: When I have a project that uses the branch aware SVN repository and I want to trigger a manual build, how should Continua be informed what branch should be built?
I was basically using a variable containing the branch, which was then embedded to the paths, but now I began to think that this may not be the correct way.
When you manually start a build (with the single arrow ‘play’ button) it should prompt you to specify the branch for any branch-aware repositories. If you use the quick start (double arrow) button it will build the default branch - in the case of subversion this is the trunk. You shouldn’t need to do anything to manage the branches manually - Continua should take care of that for you.
As discussed in the other thread, you can use $Source.Repo.Branch$ to find which branch is being used and perform different build steps etc.
Cheers,
Ben
While checking out the newest beta one additional question popped up:
How should we go about building once-off builds?
We have occasionally the need to provide a hotfix for a specific issue to a customer. To avoid unwanted changes and regressions, we provide this hotfix on top of the most recent maintenance version released. The hotfix therefore does not contain any other changes (except if a hotfix has already been made for the customer).
How we do this is that we tag all releases. When a hotfix is required we create a new branch from the tag, and merge the specific fix for the customers' issue to that branch, and then build it with special settings for example by omitting installer builds etc. You can find this facility in our delivered build script, that we can checkout and build arbitrary branch at will.
For vast majority of the cases these hotfix branches are once-off -items meaning, they are created and built once and never used again. Therefore it would be bit excessive to have them being synced to the Continua server from the repository.
How should we go about building these once-off branches, as they are still using the same configuration as the main build?
Also, when you have the reworked agent sync available please let me know so I'll take a look that it works for us.
Hi Olli,
The branch-aware subversion functionality works by syncing the entire subversion source (ie all branches), so your short-lived hotfix branches will already be tracked by Continua.As a general rule we try and minimise what we sync, but to give subversion the same sort of branch awareness as DVCSs like git and mercurial, we had to be a little heavy handed. The good news is that we only sync differences, so once there the hotfix branch has been sync’d to the agents the first time there’s no additional overhead (other than disk usage).
In terms of not building the installer etc, you can define a variable (eg MakeInstaller) in Continua which you pass to FB. You can set the prompt type to boolean, then whenever you manually start a build (using the single-arrow start) you’ll get to set the variable. Or, you could pass $Build.YourRepository.Branch$ to your FB project as a variable and only build the installer for certain branch names.
We started with the second option, but ended up changing to use a variable because sometimes we needed an installer for testing a non-standard branch build.
Cheers,
Ben