I am trying to understand how to setup an incremental build in Azure Devops using gradle as build tool.
So far, I have tried to run gradle with --build-cache and I am caching the $GRADLE_HOME/caches directory. In my understanding that should include the build cache.
It's not working however. When I run the gradle build locally, with all build directories removed, gradle is going to be able to skip about 80% of the build time by skipping 70/200 tasks when using the build cache.
When I run the same config on azure devops, however, gradle does not skip a single task, and therefore takes rather long.
I am sure, I must be missing something - but what is it? a
Related
According to Built-in cacheable tasks the gradle task "test" supports build caching. I wonder how the build cache works, if I run gradle clean between 2 gradle test executions. Since gradle clean deletes the test results (assuming these are parts of the output of gradle test in the build cache context), the cache won't work here. Is that correct?
Some background:
We've got a multi-project setup in gradle and would like to skip tests in subprojects, when there were no changes.
The build cache does not store the task outputs in the project workspace, but in a local or remote build cache. The local build cache lives in the Gradle user home.
So the cache will work, even if you run clean, since the outputs of the test task are stored in the build cache and are not removed from there by running clean.
I'm currently trying to migrate a project from Gradle 3.5 to the latest Gradle version 4.9. and I'm running into the problem, that Gradle doesn't find the resources that it needs to execute the junit tests. These resources are generated upfront and contain some configuration files and referential data.
The project uses a combination of npm and Gradle to compile. Usually we run a npm script which executes a couple of tasks sequentially using run-s, e.g. webpack builds to generate some static resources. At the end we compile everything together using Gradle. The last Gradle task also executes the junit tests. This step fails and makes the whole build fail. The Gradle runner complains that some resources are not found, although the get properly copied to the right places.
When I execute ./gradlew test --rerun-tasks (Yes, we use the wrapper, which has been properly upgraded, too) right after the last Gradle build step failed, it executed the junit tests successfully.
I know, that the directory structure changed in Gradle 4.x, but this doesn't seem to be the problem.
My suspicion is, that it has something to do with how we normally run the whole build process. Something in the combination with npm.
I'm trying to set up a deployment pipeline using GoCD as follows:
Compile, test and deploy to Maven repo
Check out source code from SVN
Run mvn clean compile test install
Run mvn deploy to deploy the WAR artifact to Sonatype repo
Deploy to Tomcat server
Retrieve WAR artifact from Sonatype repo
Run mvn tomcat7:redeploy to deploy it to the Tomcat instance I have running
The thing is, I can't seem to split 1.2 and 1.3 (for example) without having to rerun the whole the entire source code checkout again in 1.3. This seems redundant to me as I had already gotten it up to the package stage and should be able to just continue to run from there.
Between 1.3 and 2.2, I can see that it can retrieve the WAR artifact from Sonatype, but I can't do much with it with maven because there's just no pom.xml for me to execute the maven task with. Of course, I can just add the source code material and run the entire mvn package tomcat7:redeploy cycle again, but I'm pretty sure that's not what this was designed for initially.
I can also write a shell script and ask Go to run it to copy the WAR file to the right location, but again, I could have done everything in one maven pass and save myself some effort but that would just reduce the entire pipeline to a single box which isn't much help to help visualize the deployment pipeline.
Can I get some advice on how I should be designing this pipeline if I wanted to split a maven task flow into different Go tasks / pipelines?
Thanks
Wong
In our web-application we manage our continuous integration using TeamCity. So far we have manually added required jars and used an ant script to build and deploy our application. Lately we switched to Maven and added Artifactory to the cycle.
I need to know how to deploy our build artifacts from TeamCity to Artifactory.
I added the Artifactory plugin to TeamCity (following this guide) but when trying to add a new build step I can't seem to find any Artifactory related step (which I expect to find).
Am missing something here?
I don't think it is a separate step but actually a set of options at the end of the Maven build step itself (it should be toward the bottom).
See here for more detail:
http://wiki.jfrog.org/confluence/display/RTF/TeamCity+Artifactory+Plug-in.
Specifically, it says "The 'Deploy maven artifacts' option will only be available when using a 'Maven2' build runner."
My build scenario is like this (simplified):
Compile
Package (*.zip)
Deploy to test environment
Run tests over the environment
If tests fail TeamCity still publishes artifacts. This is unnecessary and consumes disk space. How can i prevent this? Can't find any check box or something (TeamCity 6.5 Enterprise).
As far as I can tell, TeamCity doesn't have a built-in option to disable artifact publishing if the build fails.
However, in the build script called by TeamCity you could try:
Removing artifact paths from the build configuration, and instead emitting the appropriate TeamCity service messages with your artifact paths only when tests are complete and successful.
Only copying files to the artifact paths configured in TeamCity after the tests are complete and successful.