I'm doing a POC for a Java project in an AzureDevops CI/CD pipeline. I created a Maven project that has Selenium tests (TestNG) that run against a demo website which is independent of my project. I want to run unit tests in the build pipeline and UI Selenium tests in the release pipeline.
The Visual Studio test task seems to be the building block that I need. I think you can differentiate between unit tests & UI tests using the 'Test files' field like **\unit*Test.dll, **\ui*Test. Unfortunately, this task is not available/compatible for Java projects.
I was able to run the Selenium tests with the Maven task and Surefire plugin during build but remember, I only want to run unit tests during build.
I actually was able to run the Selenium tests in the release pipeline via a workaround which was:
Copy the whole project to the artifacts directory of the release during build (copy files task).
Add a Maven task to the release pipeline
Trigger the Selenium tests in pom.xml
Normally, you would only copy artifacts to the artifact directory so I think doing that is a huge hack.
Another problem is that Maven will build the project during build and release which is wasteful. To dial back the waste, some savvy Maven configuration might help. I was thinking about skipping compilation and resolve dependencies during release, but I don't know where to find the Maven dependencies in the DevOps ecosystem.
Am I missing something or is AzureDevops maybe not supporting Java all that well?
I do follow a method for Maven selenium tests on Azure DevOps. What I do is, in the build pipeline I build my tests in such a way that it produces a jar with all the dependencies and test classes in it. I also use testng in my approach. Next I copy my build Artifact to Artifactory. This completes the build. Now during the release I download my Artifact from Artifactory and I check the environment where i want to run and I inject the right testng file by running java -jar myfile.jar testngIT.xml. This runs my tests faster and better.
You can try just adding a test task in your release pipeline just as in the build pipeline.
And add a copy task in the build pipeline to copy the test codes and files to the build artifacts and publish it to release pipeline.
Below steps is just for reference(in classic view). Hope it can be of some help.
1, Add copy file task in the build pipeline to copy the all test files and all the dependent setting files to the test folder in artifacts.
2, Publish artifacts to release pipeline
3, In the release pipeline, add the task to execute the tests just like the way you do in build pipeline
Related
I'm working on automating SVN Tag generation through JAVA and need some suggestions to start of with. This is how we do it manually - Check out a maven project/plugin from SVN repo and run a set of maven commands (mvn clean test, mvn release:prepare) to generate SVN tags, mvn release:prepare is the final command that would run unit tests, generate the tag and commit it to SVN and I'm working on automating this process.
I had a look at svnkit api which I can make use of to check out a project to the local file system and find a way to run the set of maven commands to generate tag URL, is there a maven JAVA plugin through which I can trigger maven commands? Or is there a much better way to do this other than JAVA?
I did my research on svn kit but could not find any relevant info to automate the maven process, probably I'm missing out on something.
It seems that you are looking for continuous integration.
I would recommend you to evaluate the use of Jenkins, which can be configured to periodically poll changes from SVN and launch a Maven build. Then, if the build succeeded and you decide to release it, you can perform a Maven release from Jenkins, which would take care of invoking the corresponding Maven goals. You can also configure a post-commit hook in SVN in order to launch a build after each commit.
Is it possible to execute a lifecycle target (e.g. integration-test) on an artefact that has been installed within the local repo?
My use case is as follows. I have a multi module project with many modules that dedicated various types of integration testing (compliance test, performance tests, etc). I need to invoke these integration multiple times with different environment configurations. These configurations are expressed as maven profiles and parameterised using properties. I want to avoid recompiling the project over and over again.
I would like to have one build CI job performing the mvn install, then separate CI jobs performing the integration tests, triggered once the build CI job has passed. The integration tests would simply invoke integration-test lifecycle phase of the installed artefact setting the profile and passing the parameters
I have tried pointing mvn at the .pom file within the local repo but this does not work. It fails because it cannot find classes within the artefact's own JAR file (as if it were not being put on the classpath) - a problem that doesn't occur if I have my integration job checkout the tree and invoke the pom.xml within the source tree.
mvn -f ~/.m2/repo/x/y/z/myproj-perftests-x.x.x-SNAPSHOT.pom integration-test -Pmyprofile -Dparam1=blah
No, it is not possible. Maven plugins (normally) only work with project sources.
If your only concern is recompiling project again and again, consider splitting your project into the core part and the integration tests part. Then when running integration tests you'll only need to recompile the integration tests part.
Currently I am working in a project that integrates Gitlab + Jenkins + Maven.
This is a Maven Java project and we have UT and Integration tests.
I designed a pipeline for the CI that looks like this:
Build Core Package and Run UT
Build WebPage and Run UT
Run Integration Tests written in Cucumber.
Deploy to a staging Server
On paper this looks good but now I am trying to implement this and I am having some issues.
Is there a simple way to save the java packages in per Git Branch? Each branch will compile and create a Jar file in step 1 that will be needed in Step 2.
In step 3 how can I use the war built in step 2 to run the tests? Currently I have all inside the lifecycle of Maven, but cannot find a way to split this.
Thanks
You can use jenkins to perform this job
I don't think you want to be putting build assets into source control. You should be able to use Jenkins to run the individual steps of your maven build and use the intermediate jar and war files that it creates in its working directory. If you can't split them out into separate steps within maven for some reason, you may need to simply do the whole maven build and then run the tests with the working files which it shouldn't remove.
I am trying to find a solution for the following puzzle. I have java projects, managed by maven, which needs some native dependencies to work (run unit and integration tests). Those are provided in form of deb packages, which needs to be installed prior to running a build.
I use Jenkins for CI. Native dependencies can not be installed on Jenkins nodes, because of conflicts with other builds and they can change often. What I do now is not to create a Jenkins job type 'maven', but 'freestyle' and use a pbuilder to create an clean sandbox, install all that is necessary and invoke maven build.
This is working great, but I am loosing Jenkins maven goodies like automatic upstream projects, trigger build when dependency change, etc. Jenkins simply does not know that maven is there.
Finally, my question. Is there a way how to achieve both, isolate build so installed libraries does not affect other builds and leverage Jenkins's 'magic' applied to maven builds and their dependencies?
You could split your build in three jobs, which trigger the next one.
Create needed environment
Run maven job
Clean Up
Even a Freestyle job has "Invoke top-level Maven targets". You could use that to get "maven goodies" while also having ability to run other build steps.
There is an option to "use private Maven repository" which will make sure it will use the .m2/repository folder location relative to the workspace. If you need to separate into multiple jobs, you can use "Custom/shared workspace" between those jobs.
Even in Maven-style job, there is an option to use private repository, so that one job does not affect another.
The problem can be solved by using distributed Jenkins builds. Slave agents can be configured to provision clean environment (e.g. via VMs, docker,...) for each build and tear it down after build is done. This way Jenkins job can be of Maven type and any changes done by pre-build step will not affect others.
More information can be found here.
Consider docker. There you can run processes in isolated environments just as you want. Docker works in a way that it easily communicates with Jenkins.
As a benefit you can also use that docker container to run local builds in the same environment as they run in Jenkins.
I had been introduced to concept of CI lately and was trying to work on jenkins CI. I was stuck up in one thing . How to trigger executable testng files in jenkins CI. For ex locally in our machines we just run testng.xml to execute couple of test cases. In the same way how can we trigger this xml file to run in jenkins CI ?
In most cases with jenkins you wouldn't use an executable. Normally you'd run the wrapper for the tests (Junit/Nunit etc.) which Jenkins is fully capable of running on it's own.
You can use this article to run TestNG tests using Maven:
Running TestNG tests using maven
After configuration is completed just add Invoke top-level Maven targets step to the Build Steps in Jenkins (Maven plugin should be installed). The target should be test in this case.
If you will face with any errors during configuration, try to google them.
If you are not using any build tool like maven or ant, you can invoke it from command line as we'll and specify your suite file. Make sure to set the correct class paths http://testng.org/doc/documentation-main.html#running-testng
You can put this as a build step in Jenkins.
Add a compilation step prior to this step. I haven't ever tried it - have always used ant or maven, but that is where I would start exploring.