The strange thing is that sometimes with the exact rules, code, configuration, etc the build fails and sometimes it passes. The stage fails because the action evaluates as False, however when I go to the workspace directory of the build the file is there.
We are using the latest version (1.0.0.2496) on both of the server and agent (both running in the same machine) on a Windows 7 Ultimate 64 bits.
Also in the morning the build suddenly stopped with the following error message:
Stage Controller The agent 'spade' which was executing stage 'Build' has gone offline This event has been reported 2 times.
Which is very weird since as I mentioned before the agent is on the same machine as the server.
I'm working on putting additional logging into the If Exists action to help diagnose the error. I'l upload a new build for you to try sometime tomorrow..
Regarding the "agent has gone offline" error message. If you turn on the Server debug log, a message starting with "An error occurred while checking if the agent is alive ... " should be logged before the agent goes offline. If you can post this message, this should help us to identify the cause of this issue.
Thank you Dave, another issue is that since the latest version Continua stopped detecting new changes in our Github repository. I enabled UDP logging and the log doesn’t show any errors:
[code] [Debug] [Repository] Getting new changesets for repository ‘GitHub-eleventa-releases’ which is in ‘Initialised’ state[Debug] [Git] GetNewChangesets -> Getting new changesets for working directory ‘C:\ContinuaCI\Rc\c754586d’. Last changeset id = 1[Debug] [Git] SetQuotePathConfig -> RunProcess with arguments ‘config --get core.quotepath’ and working directory ‘C:\ContinuaCI\Rc\c754586d’[/code]
The only way we can “force” Continua is to reset our repositories however this takes a fair amount of time and it’s not very practical.
The minimum agent version has changed so you will need to update your agent(s)
With this installed, any errors with the If Exists action will be added to the build log.
Did you find any further errors in the Server debug log related to the "agent has gone offline" error message?
Regarding the Git issue, we would need some further information to diagnose the cause of this. There should be further [Git] / [Repository] messages logged after the ones you have posted. Can you send the full debug log to support@finalbuilder.com? It would also help if we had some further details about your repository set up, such as a list of field entries in, or screenshots of, the repository dialog?
Hi Dave, thank you I’ll install this hotfix version and I’ll let you know. I’ve left running the Console app in the server to check for errors. Today when checking the Event log in the web interface there’s a new error:
This suggests a problem with git, either locally or remote. It could also be a comms issue with connecting to github. If you go to the eventlog and resolve the error then the repo should try again. We’ll take a look at this again on monday and see if there is anything else we can do to handle this situation (it may already be doing so, I’m not sure).
Thank you Dave, I didn’t know I was supposed to click “Resolve” for Continua to start trying again, may be that was the cause. May I suggest adding that information in the Event log section since I thought that “Resolve” only made the error “go away” (like a archiving an email), just a usability suggestion.
I’ll try resetting my repo and solving all the errors and hope that Continua starts triggering the builds from the commits.
I just checked and the error should have resolved itself. The Repository Monitor will stop monitoring a repository that is in the error state for 2 minutes and then try to resolve the error itself after the 2 minutes are up. It will keep trying resolve the error untill it’s resolved or the user changes something.
We have a bunch of github projects building on our internal build server (some we use or contribute to, some just for testing) and we had the same error 128, I guess github went down again (seems to happen a bit lately, getting ddos attacks), when I checked those repos they were all working fine without any user intervention.
Hi Dave, thank you, but I’m still unable to make Continua start detecting the changes in Git again. The only way is to reset the repositories but as you know it’s not a practical solution.
The last error I received was:
[code]Git An error occurred while updating submodules to Git repository cache related to changeset ‘6dfe9b8d55dab399f3ec9407a666c89dae172f78’. Did you forget to push changes to the submodule? Git message: Cloning into ‘externos/DelphiMocks’…Submodule path ‘external/SubModule1’: checked out '8e283847b820122bba0f03ac274c0ef94232226d’Submodule path ‘external/SubModule2’: checked out '4f34e439afdc87bad64cc0002fd65272295ac07e’Submodule path ‘external/SubModule3’: checked out 'bb07ec1adf316932bc62b84112e5d39df8290ebe’fatal: reference is not a tree: fdcdff07a3964065f85d45daf0c9500023b6d02bUnable to checkout ‘fdcdff07a3964065f85d45daf0c9500023b6d02b’ in submodule path ‘external/SubModule4’ [/code]
However I cannot replicate that error checking out the code myself. Any suggestions?
This error usually means that a submodule change was committed in the submodule folder of the main git repo but not pushed, and then a change in the main repo was committed and pushed. When this happens, the the submodule reference is pointing to a commit that doesn’t exist on the remote submodule repo.
When you test locally are you cloning with the --recursive option or doing submodule init/update (for older versions of git), if not, then you wouldn’t see this error.
Note, after pushing changes to the submodule you will also need to go to the Changes tab on the Configuration view, hover over the Changeset Id and click on the Resolve link.
Hi Dave/Vincent, well I’ve tried everything, cloning the main repo in Git outside Continua, and the message never comes up in my tests (and hasn’t showed up in Continua all day today), I’ve also tried to change to every branch I have (like 5) in my tests and the error doesn’t show up again. I’ve also resetted the repo in Continua and everything “works” however Continua stops getting new changes and I have to reset the repository every time I want to pull the new changes.
I am considering uninstalling and reinstalling everything however I have a fairly (and time consuming) configurations, Is some sort of export configuration available for re-importing later?
Hi Dave I’ve attached the log for the latest half hour, at 5:39pm I made a commit to our branch “develop” which our configuration “beta” is set to trigger the build when a commit is detected in this branch. I’ve made sure to push the commit to GitHub.
Everything seems to be OK in the log. However as you stated running Git fetch is returning no changesets. This could be because we already have already fetched all the changesetsbut they did not match the branch pattern. Can you send details of the repository settings? Are you monitoring all branches or just one? Are you using a branch pattern?
[code]A new event has been added to the event log: Repository Cannot get new changesets for repository GitHub-eleventa: Running git.exe with arguments “fetch” failed and threw exception: "Running git.exe with arguments “fetch” failed with return code 128 and error output: “fatal: unable to access ‘https://930224f23520cb5d:*************@github.com/bambucode/eleventa.git/’: Empty reply from server” [/code]
But I can checkout manually the repository and ping correctly github.com, Do you know what error code 128 means?
We've found an issue with the way that we are checking the results from GitHub repositories.
We are matching the url from the "fetch" output with the repository url. This is something we added recently to deal with an issue with submodule changes being added to the main repository, however we are not taking into account that GitHub urls can end with ".git". If you remove the ".git" from the end of the repository url, then the changes will be detected correctly.
We will get a new build out today with a fix for the bug allowing to continue with your current settings. Thanks for reporting this.
With regard to the error code 128, this it usually a network connection issue. This can be ignored if it is not repeated.