I am a newbie with Azure CI/CD. I was trying to setup a release pipeline to run the Specflow tests. However I am getting the below error after running the Vstest agent
VSTest Agent Log Screenshot
I can successfully the build the project and below are the release pipeline setup:
Although I don't see in the "Download Artifacts" stage that test libraries were downloaded to the test directory
Download Artifact Log Screenshot
All my tests are running fine on Visual studio local. It's a .Net5 project.
Related
I am a newbie for CI & now start using Bamboo server for continuous integration. I've just get running Bamboo server and set first plan. I set the task for source checkout. Now I am trying to add automated build for my app.
For now app is just simple console based example running both at windows and linux. I have makefile associated with app to build it and then I run .exe (win) or ./ (linux) manually.
Now I want to set the "Builder task" (script task), how do I automatize it building it with Bamboo?
Yes, you have to add "Script task" and call your makefile to build your application in it. You also would need to define an Artifact - providing relative path to your .exe file. (Artifacts tab within your job configuration, more info here) so you can download your .exe file when the build is finished.
Depends on where you bamboo is running
If the Bamboo is on linux machine , just script task would be enough . To build it on windows environment as well , you need to have windows agent or use winexe to call it remotely .
I just installed the latest version of sonarqube on my server and did a test run on my project with the sonar-scanner executable. This works.
In the next step, i'm creating a new VSTS Build Definition with the existing SonarQube build steps.
When I trigger this build, it fails in the last step, after the report has been uploaded to my SonarQube server:
VSTS build log
SonarQube server log
I don't know why this happens, because the sonar-scanner is working just fine. I'm using the same parameters in my MS Build step.
Looks like your VSTS task is pending completion of the Background Task on SonarQube server side, as per this log in your first screenshot:
Waiting on the sonarqube server to finish processing in order to determine the quality gate status
(note: this is a log from the VSTS task itself, not from the SonarQube Scanner which did finish successfully)
The problem is that the Background Task actually fails with an error as per your second screenshot. The failure corresponds to bug SONAR-8013 (fix to be released in upcoming SonarQube 6.1).
I am experimenting the use of Rational Asset Manager to store our binaries and/or build artifacts. I am running a mvn deploy command to deploy my build artifacts to RAM. Although it recognizes the connection its throwing me a Http status code: 500 error.
I have also checked RAM logs for more information but i don't see any specific exception. All the examples or documents out on internet says we have to configure RTC build engine to run the builds.
I just want to know if anyone have tried publishing to RAM from command line using Mvn deploy ( without using RTC client ) ? is this do-able?
If you have successfully published artifacts to RAM using maven, can you please elaborate on how you did it?
It seems to be possible, if you follow the steps described in:
"Creating and using Maven assets", and
"Deploying from Maven to assets":
Before you can use Maven assets, a repository administrator must enable the Maven model library. For more information, see Enabling the Maven library.
The mvn client can integrate with Rational Asset Manager, using Rational Asset Manager as a Maven repository.
Before you deploy from Maven to Rational Asset Manager, you must add a repository entry to the pom.xml file on the computer where you plan to run the mvn client. See Creating and using Maven assets for more information.
I was able to deploy the artifact using mvn deploy after changing the following things in RAM
Pointed to a JRE version in RAM ( originally was pointing to JDK
version) and
Changed permissions for my role for saving my artifacts
in RAM ("save Work Item") Reference
As I'm using Selenium/MSTest for UI tests, I got a problem: I need to deploy an ASP.NET site to a staging server just before the automated tests are executed during a TFS build (TFS 2012).
Although I thought I could do this configuration in the TFS Build process template (DefaultTemplate.xaml), I can't figure out how to change the order to execute a Build->Deploy->Test flow.
Note I've found some how-tos aiding in this goal when using TFS Lab Environment, but this isn't my case.
Default Template Unit Testing is different from UI Testing. Default template is designed to run Build -> Unit Test -> Deploy.
You are now in Build -> unit Test -> Deploy -> UI Test.
For UI Testing, You need separate Test Agent and set up build agent in interactive process.
These links may help
http://www.deliveron.com/blog/post/Configuring-a-TFS-2010-Team-Build-Server-to-Run-Coded-UI-Tests.aspx
http://blogs.infosupport.com/testing-your-web-application-with-selenium-and-mtm-part-1/
http://blogs.infosupport.com/testing-your-web-application-with-selenium-and-mtm-part-2/
Finally I've solved the problem chaining builds.
For example, when I queue a production build, this is the sequence:
Build, deploy to staging without UI tests
Build, no deploy, staging UI tests only
Build, deploy to production without UI tests
Build, no deploy, production UI tests only
I got the solution from this blog post:
http://blog.stangroome.com/2011/09/06/queue-another-team-build-when-one-team-build-succeeds/
Post's author posted the modified DefaultTemplate.xaml (build definition) in GitHub Gist:
https://gist.github.com/jstangroome/1196590/
Credits for the whole blogger!
One simple solution is to have an intermediate msbuild project file that is specified in your build definition and from there, call the actual solution file.
You can then do whatever is required pre- or post- build to ensure that the environment is up and running prior to TFS executing the tests. We do things like compile and deploy databases prior to TFS running our integration tests.
This is one solution that avoids having to manipulate the build template.
Note: This question has been originally posted by Lahiru Gunathilake as an answer to another question. I'm moving it here as a separated question for the sake of clarity.
When we are doing a release we just build in our local machine and do the QA and then we host it in to repository. If we run mvn deploy does it create new artifacts, this cause having different artifact in the repository and in binary distribution because we are creating the binary distribution from our local repository. But if someone get the source code and do the build they'll get a different one. But if mvn deploy doesn't build but only deploy it's fine.
As explained in Build Lifecycle Basics:
A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the Lifecycle Reference):
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify the package is valid and meets quality criteria
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.
To do all those, you only need to call the last build phase to be executed, in this case, deploy:
mvn deploy
That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase.
So, the answer is yes, mvn deploy will execute install and build the project artifacts. But if you don't change anything, this will produce exactly the same artifact.