I just started using docker and wanted to also use gitlab-ci for builds and tests. After painfully long and numerous attempts I finally managed to prep my images and gitlab-ci.yml. My project consists of WebApi, database project and test project.
My current flow is (using docker/compose and dind in gitlab-ci):
Build stage:
build webapi and load it to container registry
build database and load it to container registry (image mcr.microsoft.com/mssql/server:2017-latest)
Test stage:
run docker-compose on compose file that prepares testing:
start database container from image in container registry build in build stage
build test project and start the container
docer execute on test container "dotnet test 'Tests.csproj'"
One more important piece of information - the test project is using Respawn to reset the database to clean state for integration tests. It basically goes through the object graph and deletes data before each tests (also handles nicely the relationships). For sql server it uses SqlConnection (abstracted to DbConnection in later stages of the code) to connect to the database.
If I run this on my local machine (manually create the database image and then run docker-compose from 2a, and manually run docker-compose -f Tests/docker-compose.ci.yml -p dockercomposeForTests --no-ansi up -d) the tests are running fine.
However from gitlab.com, tests are hanging on the Respawn. They stop exactly on DbConnection.CreateCommand(). At this stage it seems to me, that there is some kind of a problem either in my setup or in the container, but afters days of trying to resolve this issue, I do not have any more ideas.
I know the database is up and the tests are connecting to it. First, Respawn is opening a working connection. Second, I also have a Hangfire starting and connecting to exactly the same database (uses the same connection string as Respawn), and hangfire is reporting connectivity (at first I had some problems with it but I left it because it helps me to diagnose if connection is alive and working; at some point I will probably get rid of it so it won't slow down the tests).
Related
I am currently working on C# selenium automation tests. My setup is simple: running tests on a test server (accessible via remote desktop), I've setup task scheduler trigger to run them every day via this command:
dotnet test --logger:"html;LogFileName=C:\inetpub\wwwroot\mywebsite\TestResults\TestResults.html" C:\AutomationSuite\Testsuite.dll
The test results output file is stored in a wwwroot foolder and is uploaded to a website that is accessible via vpn.
Visible output:
Now, my question is: are there any extensions or convertors for my test results to be more appealing to the eye? Like in a pie chart or something like that (running on azure devops the output of test run is more appealing).
Is it possible or am I digging too deep?
Much appreciated
Managed to set it up using AllureReport
After submitting a build though Azure Dev Ops, we noticed that the command to build the migration steps timed out after an hour of inactivity. It only happened on this branch and we've completed others before and since successfully. The solution builds and runs successfully.
Upon investigating, I narrowed down the issue to happening on the following command:
dotnet ef migrations list --configuration Release --project <repo_project_name> --startup-project <startup_project_name> --no-build --context <fully_qualified_context_class_name>
When I run the above command in Powershell,it after spitting out the list of migrations in the project, it just hangs and never returns to a prompt.
I've seen other discussions of similar issues suggesting to delete the obj folder, but when I do that in the startup project folder, I get a message that it's missing the project.assets.json. (When I do it in the repo project folder, it hangs as before. But even if that did resolve it locally, how could I implement that on the ADO server?
To make matters weirder, this particular branch didn't even update the repo project.
Any thoughts as to how I should proceed? Thanks.
UPDATE: I've been able to narrow down that we're waiting for a thread to end. This is the call stack at the point where it's hanging:
System.Private.CoreLib.dll!System.Threading.WaitHandle.WaitOneNoCheck(int millisecondsTimeout)
System.Private.CoreLib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout)
System.Diagnostics.Process.dll!System.Diagnostics.Process.WaitForExitCore(int milliseconds)
dotnet-ef.dll!Microsoft.EntityFrameworkCore.Tools.Exe.Run(string executable, System.Collections.Generic.IReadOnlyList<string> args, string workingDirectory, bool interceptOutput)
dotnet-ef.dll!Microsoft.EntityFrameworkCore.Tools.RootCommand.Execute()
dotnet-ef.dll!Microsoft.EntityFrameworkCore.Tools.Commands.CommandBase.Configure.AnonymousMethod__0()
dotnet-ef.dll!Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(string[] args)
dotnet-ef.dll!Microsoft.EntityFrameworkCore.Tools.Program.Main(string[] args)
The issue turned out to be a process we developed was not shutting down properly after script generation. The reason for that seems to be that "dotnet ef migrations" only does a partial startup of the website. It calls Startup.ConfigureServices but not Startup.Configure, which is where web shutdown functions are configured, so I'm theorizing that Dispose methods don't get called properly, resulting in our process not shutting down correctly.
I worked around that by implementing the suggestion found in this answer to another question.
All backendtests works fine locally and on one of the TeamCity agents, but always fails when another TeamCity agent tries to run them.
I logged onto all agents, and can't find any differences between them.
Other issues I have found with 'Unable to find testhost.dll' error, have been solved with referencing Microsoft.Net.Test.SDK, but that doesn't work.
In the logs for the agent working:
[10:52:07][vstest] Starting test execution, please wait...
[10:52:09][vstest] NUnit Adapter 3.13.0.0: Test execution started
In the logs for one of the agents not working:
[12:27:56][vstest] Starting test execution, please wait...
[12:27:57][vstest] Unable to find D:\TeamCity\BuildAgent5\work\b75e42d21fae163\tests\UnitTests\bin\Release\netcoreapp2.2\testhost.dll. Please publish your test project and retry.
[12:27:57][vstest] Test Run Aborted.
Everything before this looks simular. I think the agents that are not working can't fint NUnit Adapter, but I have no idea why. I checked the folder over and all agents had both NUnit3.TestAdapter.dll and NUnit3.TestAdapter.pbd in the same versions.
1. Background
I'm currently working on the following build/deployment pipeline:
Github (https://github.com/devedse/DeveMazeGeneratorCore)
Travis Build (https://travis-ci.org/devedse/DeveMazeGeneratorCore/jobs/196910720)
dotnet restore
dotnet build
dotnet publish
docker create image
docker publish image to hub
Docker image hub (https://hub.docker.com/r/devedse/devemazegeneratorcore/)
Use Azure Web App on Linux to execute deployment (http://devemazegeneratorcoredocker.azurewebsites.net/api/mazes/MazePath/512/512)
.
2. Problem
Whenever I push something to the Github repository, a build is kicked off and step 1-3 are being executed correctly.
However, the website on Azure is unreachable.
I used SCM to browse to the debug console (https://devemazegeneratorcoredocker.scm.azurewebsites.net/DebugConsole/Default.cshtml (for future reference)) and executed the following commands to find the log files that were generated by Docker:
and then used the following commands to read them:
cat docker_128_err.log
cat docker_128_out.log
The out log showed the following results (which seem correct):
Login Succeeded
latest: Pulling from devedse/devemazegeneratorcore
5040bd298390: Already exists
fce5728aad85: Already exists
76610ec20bf5: Already exists
51ee4768b31d: Already exists
4dc55ff439a1: Already exists
9cb727c7d7a0: Already exists
2bea08464ad0: Pulling fs layer
2bea08464ad0: Verifying Checksum
2bea08464ad0: Download complete
2bea08464ad0: Pull complete
Digest: sha256:647f3db3daa3330b7eb109a1c604e5bd403c2c7089b3c18c5e9249a9805d3a4d
Status: Downloaded newer image for devedse/devemazegeneratorcore:latest
Login Succeeded
latest: Pulling from devedse/devemazegeneratorcore
Digest: sha256:647f3db3daa3330b7eb109a1c604e5bd403c2c7089b3c18c5e9249a9805d3a4d
Status: Image is up to date for devedse/devemazegeneratorcore:latest
The error log however, shows the following errors:
2017-01-31T13:11:46.757760723Z No executable found matching command "dotnet-/home/DeveMazeGeneratorCoreWebPublish/DeveMazeGeneratorWeb.dll"
The strange thing is, is that whenever I run the image locally, it all works fine:
docker run -it --rm -p 0.0.0.0:5001:80 devedse/devemazegeneratorcore:latest
Somehow there seems to be a difference in running a Docker image on a Linux machine in Azure, compared to my local Docker installation which runs the Docker images on the default VM that's being installed when you install Docker for Windows.
3. Configuration files used:
.travis.yml: (https://github.com/devedse/DeveMazeGeneratorCore/blob/master/.travis.yml)
Dockerfile: (https://github.com/devedse/DeveMazeGeneratorCore/blob/master/Scripts/Docker/Dockerfile)
4. Summary
So summarizing, it seems that running Docker on Azure is being executed in a different manner then when doing this locally. Does anyone have an idea on what this could be/how to solve it?
Again, (just for easy reference), the error:
2017-01-31T13:11:46.757760723Z No executable found matching command "dotnet-/home/DeveMazeGeneratorCoreWebPublish/DeveMazeGeneratorWeb.dll"
Modify your image to put your application bits somewhere other than /home.
/home is where Azure App Service on Linux bind-mounts the persistent site volume, which is a disk that is shared across instances and is persisted between restarts.
You don't have to use it (you may not have any use for it when running your own image), but anything in your image's /home will disappear at runtime.
I have been unable to get my CodedUI test project to run. The goal is to have it run on a separate machine (virtual machine). I've configured the test controller and agent on the VM. I've also set it to run as interactive process (details below). When I run my build it partially succeeds and the following test error is reported:
Error calling Initialization method for test class XXXX.CodedUI:
Microsoft.VisualStudio.TestTools.UITest.Extension.UITestException: To
run tests that interact with the desktop, you must set up the test
agent to run as an interactive process. For more information, see "How
to: Set Up Your Test Agent to Run Tests That Interact with the
Desktop" (http://go.microsoft.com/fwlink/?LinkId=255012)
I've performed the following steps:
I've installed a Test Controller and Test Agent to VM (separate from TFS server)
My Test Controller was set "Register test controller with Team Project Collection". I've removed the checkbox! This caused a different error when running my build so I removed the checkbox.
My Test Agent is set to the test controller - set to interactive process - screen saver disabled
I have added a Test settings file to my solution.
Test Execution Method: Remote Execution
Controller shows my controller
Manage Test Controllers shows my Test Agent as Ready!!
Resources I used:
http://msdn.microsoft.com/en-us/library/ee291332.aspx
http://msdn.microsoft.com/en-us/library/dd695837.aspx
After performing all the steps I'm still getting the same error. What could the problem be? My test settings seems to correctly point to the test controller. The test controller and agent seems to be configured correctly. Do I need to use Lab Management to have these tests run on a VM?
Thanks!
You need to configure a Standard Environment in Lab management so that tfs knows where you are sending the tests.
http://nakedalm.com/standard-environments-for-automated-deployment-and-testing/
Should only take you a few minutes to setup.
Alternative set up is the following (without Lab Management environment):
1) do NOT register test controller with a Team Project Collection
2) have your agent set up to interact with desktop
3) in your solution - create testsettings file for the coded UI test run, point it to your test controller
4) in your build definition - set up automated tests to use this newly created test settings file
I am trying to run coded UI test in MTM when build is triggering in TFS2015. set up is done with test agent and test controller and created LabEnvironment. When I trigger build then build is success but test case is not executed showing below error .Enabled interactive window in test agent.
MTM, Test agent , test controller, TFS installed in my same machine (Local machine)
I'm purposely running test cases during the build. This is going to be a build that kicks off my CodedUI tests.
Error calling Initialization method for test class CodedUITestProject.CodedUITest1: Microsoft.VisualStudio.TestTools.UITest.Extension.UITestException: To run tests that interact with the desktop, you must set up the test agent to run as an interactive process. For more information, see "How to: Set Up Your Test Agent to Run Tests That Interact with the Desktop" (http://go.microsoft.com/fwlink/?LinkId=255012) If you are running the tests as part of your team build, you must also set up the build age