I have some dockerized F# tests written by expecto and fscheck frameworks, as a dotnet core standalone executable.
How to configure continuous integration on Team Foundation Server to run them and get the report after each run accordingly?
If you mean you already have the docker image which has the proper SDK/envirement, then you just need to run the image in TFS with CI build (Configure continuous integration).
To run the image, you need to install the Docker Integration extension, please refer to Build, push and run Docker images with Visual Studio Team Services for details.
Other articles may help:
Running Selenium Tests in Docker using VSTS Release Management
How to run .NET unit tests in a docker container
Configure Expecto to output NUnit-equivalent XML files with https://www.nuget.org/packages/Expecto.TestResults/
The docs are here https://github.com/haf/expecto/#testresults-file
Then just run the executable and have the CI server pick up the outputted XML file.
Related
I have several .NET Core builds running on an Ubuntu Linux agent in TeamCity. The builds actually take place in a Docker container which uses the official Microsoft .NET Core SDK image for Linux.
I have 3 build steps, all of which essentially use the dotnet CLI commands within the docker container:
dotnet restore
dotnet build
dotnet test
The build works great - the assemblies get versioned correctly per GitVersion, the tests run, I get code coverage data via dotCover, etc.
The one thing that doesn't work is that I can't find a way to set my build number based on GitVersion. I believe this is because GitVersion is running inside the container and therefore it is not aware of the TeamCity agent, nor the agent of GitVersion.
So that's my challenge. Remember, this is running under Linux so I can't use an Windows specific tricks. So how do I get GitVersion to somehow "publish" the build number out of the docker container and back into TeamCity?
Basically i want to run my SoapUI tests (ReadyAPI is downloaded on my computer). With Teamcity, which is running in docker container.
So i started my Teamcity server and agent in docker container. Like this: https://strangeway.org/2017/12/%D0%BF%D1%80%D0%BE%D0%B1%D1%83%D0%B5%D0%BC-teamcity-%D1%81-docker/
After that i installed SoapUI pro plugin (SoapUI Pro Functional Testing) into my teamcity server.
To start a build in Teamciy using SoapUI Pro Functional Testing it is mandatory to give a path to testrunner shell script into Teamcity server.
My question is: how do i give path to a shell script that is located on my computer to a Teamcity server that is running inside a docker container?
hard way.
map your local directory to your TeamCity container.
use this volume(inside the container) in your test build step
best way
store your tests to VCS like git.
add VSC roots to TeamCity Server
attach VCS to your build
use files in the build steps
There are many similar questions like this, but my scenario is slightly different.
I use Visual Studio Enterprise 2017, dotnet Core app 2.0, on a Windows 10 Pro machine, where is running docker for windows.
I can run and debug my applications in my local machine's docker server, but now I would like to configure visual studio, for my current project only, to run the application in another docker server.
So in practice instead of running commands such as docker run, docker build and so on, I would like it to use docker --tls -H={theotherdockerserver} build ...
I could not find so far any parameter or configuration section that allows me to do so.
You need to have all your files accessible from remote server. One way to do this is to put your code in GitHub repository and run command: docker --tls -H={dockerserver} build https://github.com/{user}/{repository}.git
Documentation for GitHub build.
Do you need an option without GitHub repository?
The TFS2017 supports build agents only on a 64bit OS and TFS2017 does not support the (32bit-)agents from TFS2015 anymore.
However, we need to run our test code on our 32bit OS to stay as similar to the production environment as possible. :/
We consider using Jenkins as a TFS triggered agent to execute the build and run the NUnit test steps on the 32bit OS, but it sounds like a high administrative load.
Does anyone have experiences to circumvent the missing 32bit TFS agent? Or do you see any other possiblitiy?
You could build your project on build agent server and run test on test agents server. Test agent could be install on both 64 and 32 bit system. Make sure the build agent and test agent are connecting.
Create a build definition all these steps:
Nuget Restore
Build solution
Copy Files (Copy to $(build.artifactstagingdirectory))
Publish Artifacts to a share folder or Server
Visual Studio Test Agent Deploy: Deploy the test agents to your 32 bit server.
Run Functional tests: The Test Drop location is where you publish your code to.
For more details: https://www.visualstudio.com/en-us/docs/test/continuous-testing/set-up-continuous-testing-builds
Note:
If the test agent can't be deploy successfully, you could install it manually. Download from here. Remember to restart the server after install test agent.
My Question: How can I run a deployment script from the TFS 2010 build template on a remote system that has only a MSTest agent running?
I know this can be done by activating the Deployment section in the test settings configuration file, but this is not flexible enough. At night a build runs. When the build is successful, a deployment script is placed at a drop location. The drop location is date, project and build definition specific. These parameters are available in the TFS build template we use.
I do not have Lab Management available, just a physical server. I would rather not spoil the physical server with an additional build agent to only do the deployment. The MSTest agent is apparently capable of running deployment scripts, but how do I use that functionality from the TFS build workflow. For example, can I use the RunDeploymentScript activity without having Lab Management?
PSExec is a great tool for running scripts on remote computers. I use this in Team Deploy that allows you to install MSIs on remote computers from Team Build. You can also run PowerShell on remote computers but it is a little more complicated to set up. Another option is to use MSDeploy. There is a command option that you can run any command on a remote computer. I usually use an InvokeProcess activity to call a PowerShell script on the build server. From the PowerShell script I have called MSDeploy to run a remote PowerShell script on a target server. It sounds bad but worked good.
You can't run the RunDeploymentScript on the target machine. You can use a modified template to deploy to a physical environemnt. Here is a good post on doing this.. The options I mentioned above do not need any agent on it. You can use the ExecuteRemoteTestRun lab management activity without Lab Management to run the MTM Tests with the Test Agent with a Test Controller that is registered to the project collection (Test Manager).
Let me know if you have any questions on any of these options.