I've got an electron app with vite/xstate/react. In development I'm seeing just a single xstate.init event emitted when starting up the app. But in production builds, I see two xstate.init events (there should only be one, triggered by xstate itself upon initialising):
I'm logging the event out (renderer process, so it shows up in dev tools). It comes from the same file/chunk, but for some reason, dev tools show two different paths to the same file (file:///Users/... vs /Users/...). This is causing some bad bugs where things get ran twice in some cases. I'm trying to narrow down the issue here. Is this some sort of issue with electron and the build files?
Related
How can we setup access to different builds so that they can easily / quickly viewed in the simulator..
We have several builds - production, development and one or more feature branches.
From a development and testing point of view, it would be really useful to be able to quickly see each of these versions of our app.
I'm just wondering if there are any services or some sort of configuration we could employ to make this easier.
I'm thinking one major obsticle might be the app id is always the same, so this would stop of from running the builds / app in the same simulator...
I'm wondering if the app could be bundled locally (perhaps from some kind of snapshot) and a script could copy in app to the simulator ?
I guess this could be some kind of tool which would use use the simulator command line tool and swap app builds.
I found a solution, all you need to do is keep a copy of the app and drag and drop it into the simulator
https://medium.com/swift2go/how-transfer-your-app-from-one-xcode-simulator-to-another-f4225da9eb7b
We have a TFS 2017 build agent executing a Visual Studio Test task to execute our unit tests. This has worked fine for several years, but all of a sudden - without any code changes - the task gets stuck.
All the tests have finished running, we see summary information, and it will sit at what appears to be the place where it would normally publish the results... but then nothing happens. We've waited 12+ hours for it to finish. This step normally takes about 90 minutes.
I've confirmed that the TRX file is being created. It's about 4MB in size. We're running a bit over 3000 unit tests.
I've also tried disabling code coverage and attachments upload inside the test task, but it doesn't appear to make a difference.
Below is a screen cap of the log output when the step is stuck.
Lastly, we have lots of other projects on this server whose tests run / publish fine, as well as TFS Releases for this same build that also run tests (integration/system tests) which work without issue.
UPDATE: We ran this build on a different build server, and it published tests correctly. So this means there is something wrong with this specific build server...
UPDATE 2: So I'm not longer sure what is happening here. The original build server we were having issues on is now working fine with no changes whatsoever. Just started working again. The other build server was working, and then stopped. Same issue. I broke up the 3000+ tests into two steps, roughly 50/50, and that worked a couple of times, but now does not. So this does not appear to be server specific, nor does it appear to be related to the quantity of tests. Debug logging offers nothing useful, as everything seems fine right up until it just stops doing anything after generating the TRX file.
UPDATE 3: Well, it's happening again. I'm not sure how to proceed. I even tried Fiddler on the build box to see if I could catch funky looking traffic, but most of the traffic I'd expect to see I don't. It's like a good chunk of the work isn't being captured (such as source downloads, reporting progress, or test result publishing) by Fiddler. Is it not over HTTP/HTTPS?
This was difficult to figure out due to the quantity of tests we're running, but I was able to narrow it down to a test that launched ping.exe:
[ExpectedException(typeof(TimeoutException))]
[TestMethod]
public void ProcessWillTimeout()
{
const string command = "cmd";
const string args = "/C ping 127.0.0.1 /t";
var externalProcessService = new ExternalProcessService();
externalProcessService.Execute(command, args, TimeSpan.FromMilliseconds(500));
}
For whatever reason, this test was leaving both conhost.exe and ping.exe "orphaned". The fact these processes were not terminating was, for an unknown reason, preventing the tests from publishing their results back to TFS. There is probably something somewhere that waits for the a process to finish and that was never happening.
Indeed, we would see a bunch of conhost.exe and ping.exe processes in both Task Manager and Process Explorer:
You'll notice the tool tip there... "[Error opening process]". I couldn't even use Process Explorer to kill these processes - although Task Manager could. Sure enough, when I killed them, the TFS build task would immediately resume and finish publishing results.
So there is clearly some kind of bug in that ExternalProcessService code we were testing (despite carefully having a finally block that terminated the process), but we are at least able to have our build tests run again without issue.
Suggest you abandon this build and trigger it again. To narrow down if this issue could be reproduced stably.
According to your description, all other builds work properly. And it worked fine for several years. All tests pass, the test report is written, but just the task hangs. Please double check if some other processes might possibly not be properly closing down.
Besides use another build agent to test again. Also try to create a newly build definition with the same settings, trigger that definition, this may do the trick.
Moreover, you could enable verbose logging for trouble shooting. To do this simply adding a build variable named system.debug and setting its value to 'true', this will contain a more detail log info.
I have a build which hangs in Jenkins. I have deconstructed the build down to a single windows command call, a directory change and a couple of echoes in an effort to isolate the problem. It would appear that the problem lies with a single call to a program executable (now the only call in my build). The build calls the program & then hangs for 30+ minutes (I cancel the build after this time) when it should take less than 1 second. Ordinarily I would be inclined to blame the executable or my misuse thereof, but for the fact that the same call (quite literally copied & pasted) in an ordinary command prompt works perfectly fine. Further muddying the waters is my knowledge of the fact that the build I'm trying implement is working just fine on another Jenkins server I know of, executable and all, and has never had an issue. I'm sorry I can't provide details on the executable in question but it's sensitive information. It may very well be the case that the executable is to blame, but the exact same call in three environments and only one hangs? What do you think?
More info on request.
So there I was, waiting for a reply when I decided to click on one of the "Related" topics on the right hand side. Lo and behold, there it was, a solution to my problem in answer to a different question. In short it goes like this:
Jenkins is a service. Services (on Windows) have a "Log On" account, of which the default appears to be "Local System". This had the effect of forcing (though I don't know why) my program out of quiet mode and thus hanging the build. Changing the "Log On" account to my own seems to have changed the behavioural relationship between Jenkins and the executable so that it now runs smooth and silent.
When we build our MVC app, we have a build process that pushes the site on to our UAT box.
Once published, We would like to run an automated tool that crawls all the links in the app and checks for broken links and any other issues (such as usability/accessibility, etc.)
What tool(s) exists that will crawl a site and generate a report a report on broken links, etc.?
Can it be integrated in to our CI (TFS) Build?
In the absence of any alternative advice, we went with this solution:
http://wummel.github.com/linkchecker/
It's working well for us. One of the key advantages of this system is that it has a command-line mode with lots of options AND it can produce multiple format reports (HTML, Sitemap, CSV, XML) in a single crawl. Other tools I've used in the past had to run multiple times, consuming more bandwidth and time.
The beauty of this is that we can add it to our build process and then automate the output. When the build is pushed to UAT, LinkChecker runs. When it has finished, the HTML output is emailed to us and the XML output is parsed. All 404 errors are raised as bugs in TFS.
Quite a nice solution.
We use a few tweaked Build Process Template, developed for TFS2010 for all of our builds, but these BPTs are not using any custom activities. We recently upgraded to TFS2012, and during the upgrade converted our BPTs according to these instructions.
This works fine, most of the time, but periodically, it coughs up:
TF215097: An error occurred while initializing a build for build definition \Project1 (Dev10)\Simple - Manual: The values provided for the root activity's arguments did not satisfy the root activity's requirements:
'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' for parameter named 'BuildSettings'.
There's nothing in any log, there's nothing visible that I can see as the root cause in any way. The only fix is to restart the Build Controller, at which time the error vanishes for a few hours. When I unregistered and re-registered the Controller, the problem went away for about a day.
The important thing here is that these build process templates do work on TFS2012, but then they suddenly stop working for no reason I can determine.
As it turns out, some builds were still using legacy 2010-style Build Process Templates. Any time someone queued one of those builds, the entire build controller started freaking out. By getting rid of those BPTs, we resolved the issue.