I'm working on an Umbraco cloud project. I pulled the website from the git repositories and built it. First thing to do there when you run the site is to restore the content that's in the development environment to the local project so we can create new features. Yet Umbraco fails to do so with the following error:
The source environment has thrown a Umbraco.Deploy.Exceptions.ProcessArtifactException
with message: Process pass #3 failed for artifact
umb://document/xxthexguidxofxsomexpagexxxxxxxxx. It might have been
caused by an inner Umbraco.Deploy.Exceptions.EnvironmentException with
message: Could not get parent with id xxthexxx-guid-xofx-xthe-xxhomepagexx.
The following artifacts might be involved:
umb://document/xxthexxxguidxofxxthexxhomepagexx
The technical details may contain more information.
I've noticed that I some strange errors occur if not everything is deployed in the development site in the cloud. So I made sure everything is published.. Still errors though... I'm kinda lost here.
Has anyone come across simular issues? And how did you fix it?
Thanks in advance?
This can happen for a number of reasons, so it's a bit hard to say what exactly the problem is in your case.
Most of the time this happens due to either a circular reference of some sort causing a state that can't really be restored. For example that could be a datatype having a dependency on a node - but the node doesn't exist in a blank new environment. The content restore then refuses to start until the structural data (datatypes, contenttypes and such) is completely in sync, but the datatypes will never be able to be in sync until the content node exists. It's a sort of catch22 situation that might need to be resolved manually.
I would suggest you contact support through the Cloud portal and they will assist you in getting your problem resolved.
Related
I am trying to setup a CI server on my Macbook, I have followed the documentation on the apple website up to the point of creating a bot and integrating my build. When I attempt to integrate the build I repeatedly get the following error:
Bot Issue: error. Build Service Error.
Issue: '/Library/Developer/XcodeServer/Integrations/Caches/14a8ea2a72904f1abcecd38b1c02196b' exists and is not an empty directory (-4).
Integration Number: 13.
Integration URL: https://DavidMcQueens-MacBook-Pro-2.local/xcode/bots/BF817C9/integrations
Description: '/Library/Developer/XcodeServer/Integrations/Caches/14a8ea2a72904f1abcecd38b1c02196b' exists and is not an empty directory (-4).
I have manually deleted the folders in this location, as well as changing the permissions incase the server was having issues writing. Each time I run, I receive the same error. Even after I have deleted the folder so it is empty before the integration.
Does anyone have any ideas on how to solve this issue? I have built my iOS application in Swift (which I believe should still work with the CI server)
I am running OSX Server 4.0 and the latest version of XCode.
I followed Apple's documentation for creating bots
Thanks,
EDIT:
After some experimenting and trying different things to see what the issue is, I disabled 2-factor authentication on my GitHub hosting. This appeared to solve the issue, despite the fact that I was generating a specific application key to get around 2-factor. It solved the issue for a small amount of time, and I managed to successfully get the bot to integrate a few times. However it appears to have gone back to its old tricks.
If anyone has any other knowledge on this, or has managed to get it working on their own machines it will be good to know.
So I believe I have solved this issue, the GitHub 2-factor authentication issue looks to be a red herring.
When setting up the bot, there is a section that says "Checkout the repository", I did not do this step because I already had the repository on my local machine and presumed that it would simply create the repository in another location, and server no other purpose.
However, after some investigation this step is very necessary. From what I understand, checking out the repository does create it again in another location, however this is necessary as this new repository is where the Bot's will pull changes into and build in order to perform the tests. I was trying to use the same repo for development and for the Bots, which it did not like.
Creating a clean checkout of the project (on the server), and configuring the bots in that project then allowed me to progress and get everything setup correctly. It comes down to user error. In hindsight, it makes perfect sense to have a separate repo for the bots (this is my first CI server setup), however the error messages were not helpful and I can't remember seeing this emphasised in the setup guide.
PLEASE NOTE: None of the answers in the link above (which I don't seem to be able to remove) helped me. As I explain below, I had already tried all that stuff
I have a web site, developed in VS2013 using ASP.NET MVC5/WebAPI2, which has several related projects such as a service layer, repository layer, etc. Down at the bottom of the stack is a class library that holds an EF model. I have separated the actual entities into another class library, to allow them to be reused without requiring the model library.
All of this has been working fine. The web site was running, and I could make calls to the WebAPI methods as well.
I just uploaded the latest version to the production server, and all is working fine there. Then came back to VS to carry on work, and when I try to run up the web site, I get an exception
Unable to load the specified metadata resource
Searching around, it seems that the cure for this is to modify the connection string to point to the actual assembly name instead of using the default . I have two problems with this, first is that none of the config files in the solution have been touched today (by me at least, and the file history form source control confirms this), so there's no reason why it should suddenly stop working after being deployed, and second, even if I add the assembly name, I get the same exception.
Anyone any ideas what I can do? I'm completely stuffed now. Can't do anything.
Edit: I tried again to specify the assembly in the connection string, and now get the exception Unable to resolve assembly. I have checked the assembly name in a decompiler, and I'm pretty sure got it right.
Edit again: I just pulled the version that I deployed from source control, and that gives the same exception, so I'm sure this is nothing to do with any files I've changed (or even that have been changed by VS). The version on the production server is still working, but the source code that drives that exact same version gives the exception. So, I'm certain that the answer is NOT to be found in the myriad other versions of this question, but is somewhere else.
Found the problem, and am posting it here in the hope that it will help someone else, as I don't think this was clear in any of the other posts on this issue.
I have a layered solution, with the web project referencing a service layer, which references a repository layer which in turn references the model project. It seems to for EF to work, whichever layer actually causes the database to be accessed requires a reference to the model project. My service layer project, which was where ToList() was being called (thus enumerating the query, and causing the database to be hit) didn't have a reference to the model project, so was failing to load the assembly.
I didn't need to alter the metadata part of the connection string either, as once the service layer had a reference to the model project, it was able to find the resources by itself. Having said that, one thing I did learn from all of this is that you can speed up the creation of the model (slightly) by specifying the assembly containing the resources explicitly, as this saves the framework having to search through all loaded assemblies to find them. I'm not sure if this will make any noticeable difference, but it can't harm.
I still can't explain how this had been working up until now, and suddenly stopped, as I hadn't changed any references, nor the way I was doing the data access. Still, it seems to be working now, which is all that matters.
Hope this helps someone.
The following issue is using the following:
AWS
PostgreSQL
Grails 2.3.3
Redis
On our account creation page, we are having some REALLY obscure functionality with the Grails withForm{}.invalidToken{} closure.
Upon hitting the page for the first time, everything works fine. You can post back to the server fine as long as you do not leave this page.
Upon leaving this page, either through navigation links or logging off, returning to the page (Again through navigation links or logging on and heading there), we can no longer submit, it hits the invalidToken closure every time.
I know AWS is involved as we took the project and deployed it to local machines both with IntelliJ and Tomcat by itself and both work fine. This issue only occurs upon deploying the WAR to AWS. (This occurs both with local builds and automated builds. They work locally but not on AWS)
We have spent almost a week on this issue trying to figure out why this is occuring, and all we have to show for it is we know AWS is somehow involved, but that's as far as we have gotten.
Does anyone have any insight into what would be causing our session to act like this?
After a LOT of searching about this issue, me and my team finally figured it out. Taken directly from our JIRA:
"This issue is caused by the implementation of tomcat-redis-session-manager used on AWS. As per their documentation (https://github.com/jcoleman/tomcat-redis-session-manager#session-change-tracking), there are "unintended consequence of hiding writes if you implicitly change a key in the session or if the object's equality does not change even though the key is updated." Specifically, the "useToken" implementation is Grails 2.3.8 is: "String generateToken(String url) { final UUID uuid = UUID.randomUUID() getTokens(url).add(uuid) return uuid }" The combination of these native implementations are there for incompatible.
The tomcat-redis-session-manager does support a manual dirty tracking mode by setting: RedisSession.setManualDirtyTrackingSupportEnabled(true); but this would require a forked build of SynchronizerTokensHolder in grails-core."
We're trying to publish our little web app here.
I've done it several times in the past and it worked pretty well.
As the tags states, its a MVC ASP.Net project coded with VS2008.
Other interns worked on that project and we tried to re-publish again and we have this error:
[IndexOutOfRangeException: Index was outside the bounds of the array.]
XXXXXXX.XXXXXXXRepository..ctor() in
E:\XXXXXX\YYYYYYY\ZZZZZZ\XXXXXXXRepository.vb:11
XXXXXXX.HomeController..ctor() in
E:\XXXXXXX\YYYYYY\ZZZZZZ\Controllers\HomeController.vb:10
Problem is, the path pointed here E:\XXXXXXX....*Controller or *Rep is located on the LOCAL machine where the dev. is made. It's as if something was hardcoded directly in our local machines in the Rep.VB and HomeController.VB. It should point in the path where we published the whole project wich is not E:\XXX\YYY\ZZZ
Anyone ever encountered this ?
Thanks alot guys
Have a nice day.
-Tom
That is just information about where to search error in source files, so those paths have nothing to do with error appearance, they just for debugging purposes - if you will compile from your machine, they will change, but error will not dissapear.
Error message indicates, that problem is, that code tries to access array element, which is not there (let's say array has 1 element and program tries to access second one).
We have a situation where our builds have stopped executing in a stable manner.
At a rate of about one every three we receive either TF215096 or TF215097 errors & the Build fails.
If we then restart the Build controller, it works again - until next time.
The errors we get are:
TF215096: An error occurred while connecting to controller vstfs:///Build/Controller/1: There was no endpoint listening at ht*p://XXXX that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
TF215096: An error occurred while connecting to controller XXX - Controller: Could not connect to ht*p://XXX. TCP error code 10061: No connection could be made because the target machine actively refused it 192.168.XXX.XXX:XXX.
TF215097: An error occurred while initializing a build for build definition \XXX: Team Foundation services are not available from server ht*p://XXX. Technical information (for administrator): The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.
TF215097: An error occurred while initializing a build for build definition \YYY: An error occurred while receiving the HTTP response to ht*p://XXX. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
Server logs provide with little info, at least we 've found nothing that helps us resolve the situation. Various searches in the Net were also not productive.
Does anybody had these/similar issues? Any ideas on how/where to look for a resolution?
Thank you very much in advance for any input!
Yeah it does sound like you have some connectivity issues. You can try enabling SOAP tracing on both the build machine and the server (if possible) to see if there is any error. If it still does not give you any new information, contact Microsoft by filing a Connect Bug to get help.
I am not sure if it will help you but I have ran into similar issues with build agents and ended up just deleting and re-creating the agent. You may try deleting your controller/agent and adding it back in. A brute-force solution but a good starting point. If that doesn't resolve the issue at least you can eliminate the controller/agent as the issue and take a look at network/server related issues.
Today is a happy day, since we managed to get to the bottom of the matter. Sorry #Duat that I'm taking away the 'answer' checkmark - but it turned out that the problem was quite different from what you (and anybody else) has predicted.
In my last update I was about to forward the matter to MS, when we realized that our Firewall was misbehaving in the name resolution. So we assumed this was the culprit & awaited for this to resolve. After this was resolved, we STILL had the same issues and we went again re-examining the situation.
We isolated the problem within our Build Process, more specific with a custom code activity included in our build solution.
I had implemented a code activity that would kick in at the final steps of every build. This activity was about gathering BuildDetails about the running build & add them as a new line in a 'BuildLog.xls'. Implementation made use of Microsoft.Office.Interop.Excel.This excel sheet resides in another server (NOT on the Servers where the controller/agents reside).
During development of this activity I was faced with issues like this, but after I was done no instances of EXCEL were left hanging. So I thought this was done & dealt with.
With try & error, we observed that when this activity wouldn't ran, no problems would occur.
With this activity running, the very first build after a build-controller reset would succeed, any next build had a certain chance to fail. Once any build failed, no other would succeed until another build-controller reset.
I have only a general understanding of what the problem was (Excel-call is DCOM, TFS services are WCF : How on earth would they interfere?! Why would this sometimes succeed and sometimes fail?! ).
The provided diagnostics were no help either, in fact they mislead us into a loop that continued for months.
If I ever find the time, I 'd like to cleanly reproduce the error & make a Server Fault question out of it...
After removal of this activity it works! I now searched in SO & found this, where J.Saunders comments: "In general, you should never use Office Interop from a server environment". It's ironic that once you get to the bottom of any difficult issue, the whole universe seems to have known about it except you...