I am new to azure devops. I have created a Rest Assured project using TestNG and Maven Dependencies. I am able to build it successfully on my local as a Maven Project. Can I create a CI\CD pipeline on Azure DevOps instead of creating on Jenkins. My project specifically requires to create Azure pipelines. I have also successfully created and build the Azure pipeline for a simple Maven project but when I try to create for Rest Assured with Maven something fails. is there any specific settings required for Rest Assured or it should be same as any Maven project-
Build error
I was able to create azure pipeline for Maven Rest Assured project. We need to select the host as Windows host( if we are working on Windows) and then download and setup the respective agent on our local machine. We can then create the build definition for Maven build using classic editor and select the respective pom.xml
Related
I am building a SpringBoot application in which i want to handle some of the cross cutting concerns like logging, caching, persistence in to a project on its own so in future other rest spring boot components can adopt it and use it as a dependency.
I am using Gradle for dependency management. My question is :-
How can i manage this concerns without publishing it to the public artifactory.
If i have to publish then which is the free artifactory i can use for my development practice
If creating jar is an option as a temp solution then how can it be achieved via gradle. Most of the examples over the internet is for creating the executable jar files.
What are the other options i can try.
How can i manage this concerns without publishing it to the public artifactory.
Publishing has to happen regardless where it will be published to. You can use a private solution such as Nexus Repository.
If i have to publish then which is the free artifactory i can use for my development practice
For development, you can simply publish to your local Maven repository. This is typically ~/.m2. Using the Maven Publish plugin, you can easily publish locally by invoking the publishToMavenLocal task.
If creating jar is an option as a temp solution then how can it be achieved via gradle. Most of the examples over the internet is for creating the executable jar files.
Since you're creating a Spring Boot library, use the Java Library plugin to create the JAR artifact and in combination with the Maven Publish plugin to publish.
In the end, there are 2-3 key components that get published when using Gradle:
JAR artifact
pom.xml: https://maven.apache.org/pom.html
Gradle Module Metadata: https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
I prefer to use gradle with Spring Boot. I have found resources about deploying to Azure with the Maven Plugin for Azure App Service Web Apps. How would one take an approach with gradle as a build system?
Well you need to separate deployment and build.
You can use Azure build pipeline task to build with gradle.
Part of that build you can create artifacts which contains your app
Then create release which will deploy jars to azure app service
I want to deploy a Java & Maven micro services application on OpenShift however I have one small issue. These micro services are dependent on a commons project
containing some common components.
How can i add the jar of the commons project ( private jar, not on public repo) to the class path of the micro services about to be deployed on Openshift?
When building the application locally we used a maven plugin which would move the jar of the commons project into the local maven repository, from where it was easily referenced via a dependency tag in the pom file.
Here are some approaches that I thought about:
use an internal maven repository
create a folder on the root of the project and use it as a local maven repo, declaring it via repository tags in the pom files
deploy a nexus repository on the Openshift cluster
The first approach is not viable since our company does not have an internal maven repository.
We also tried the third approach , however we did not manage to deploy a running nexus repo on Openshift.
The only viable solution left is the second one, however I am a little bit reluctant to implement it since it does seem to be the standard way of doing things. What approach would you reccommend?
create a folder on the root of the project and use it as a local maven repo, declaring it via repository tags in the pom files
This won't be a good approach TBH.
My recommendation would be using a nexus/jfrog etc. repo OpenShift internal or externally (a more recommended approach for enterprises) and get the commons and other libraries from that repo via defining maven dependencies.
I know we can use the maven plugin to deploy the application to GCP. E.G
mvn appengine:deploy
But for certain reason, I would like to deploy the application not from the source code, but from artifacts repository (like Nexus).
What I want to do is to fetch the war from Nexus and use some command line to deploy the war to GCP. Anyone know how to?
I didn't find a way to do it but if you are interested in such functionality, you can use Cloud Source Repositories, which provides private Git repositories hosted on GCP.
You can use them to deploy in App Engine and even automate the process.
If you need to specifically use Nexus, you could file a feature request for App Engine.
I have a Maven component service that I package up as a WAR file. I would like to create another Maven project that builds a fully deployable Jetty container with a few custom configurations and contains my component service in it so that I can test my WAR or even deploy it. My questions for this scenario are:
Is it common to want to keep the WAR build separate from the distribution build? My thoughts behind doing this is that someone may not want to use my custom configured Jetty container. Maybe they want to create their own build with Tomcat or something else.
If this is a common thing to do, what packaging type should I use for the custom Jetty container project? It seems weird to me to use JAR or WAR since that isn't the actual artifact that ends up being built. And using "pom" packaging seems equally strange since I was under the impression that that is used for parent projects of submodules.
Ad 1. Yes, this is how I usually structure the project. There is an app project which is a container for application and a separate deploy project to handle the infrastructure. Regardless if it's building a container image, deploy to app server or whatsoever.
You can see it in an example project I've once created for a Devoxx presentation.
Ad 2. Default packaging (hence jar). If all you have in a project is a pom.xml (without any classes), no additional jar will be created nor installed. In the project I've mentioned the pom.xml contains only docker image creation 'logic'. In your scenario it will be jetty related plugin. No additional artifacts will be created.