Not sure quite how to explain this one. We've got a build where a certain repo isn't showing up in the 'changes' tab of the build, when we've set it to associate 'Most recent changesets'. All of our repos are Mercurial (8 are associated with the build).
A few things of note about the repo in question:
It's the only repo we've told to use a branch other than default
There is another Continua repo pointing at the same soruce but on the default branch (not associated with this build)
The repo is not copied to the agent until stage 4 of the build, whereas all others are at least partially copied in stage 1
It's not getting new revisions despite its polling frequency being set to 60 seconds (editing and saving the repo again aren't solving this either)
No errors in the eventlog. Is this possibly related to known issues?
Hi Joel, for the repo that's not working, can you check which branches the repository was setup to monitor? If you edit the repository, check the field "Branches to Monitor". I have a feeling it's set to "Single Branch" and the branch value is "default". You probably need to change the "Branch name" value to the branch you want to monitor.
Once you select “All branches” it changes which options are shown for triggers and when manually starting a build. Lets say you have a Repository Trigger… if you edit that, you will now see an additional field called “Trigger from”, from the dropdown you can choose to select all branches, default branch or branch by pattern. If you manually start a build and you get the prompt dialog (single play button icon) then you get to type in the branch you want that build to use… if you selected the quick start build (double play button icon) then it will automatically select the default branch.
We’re trying to figure out what could have caused this. How were your builds being started (triggers, manually)?
Are the changes from before you restarted the server showing up on the config changes page?
The only thing I can think of is that the repo was in some sort of error state, but then I’m pretty sure build 926 has some changes we made so that if any repo associated with a config is in an error state it will not start a build for that config (no point, since it will just fail anyway as you won’t have the source). We’ve been working on improving how repository errors are handled, so they should at least show up under the admin\repositories page(or the config wizard repositories page) as errored (shows a warning triangle next to the
We should have another build ready tonight, Vinnie is busy uipdating the build server with the latest build and then we’ll fire off a beta build. There are quite a few bug fixes since the last build.
Yes, the changes that were missing before the server restart are appearing in the configuration changes after the restart. I have had repos in an error state stopping builds before (with build 926), but I was able to resolve and continue. I’ll throw 930 on and have another go.
930, the repo is still not showing up in the build changs. Here's why I assume it should be showing, the repo in question is 'SingleUserInstallScripts'.
Can you check if the repository is disabled? If the repo is disabled then the changesets will not be associated with the build. I’ll look at adding more status information to the timeline when the changeset association is done.
I’m at a loss to explain what is going on here. We’ll add some more debugging info on Tuesday (Monday is a pub holiday here), hopefully that will shed some light on the subject. We’ll also test with a lot of repositories assigned to a config, as I’m not sure we have really tested with more than 3 or 4 repos on a config.
