No matter what I write to .travis.yml Travis CI always executes ./gradlew assemble. I would like to run ./gradlew test instead.
Contents of my .travis.yml:
language: java
script:
- ./gradlew test
Feel free to fix my failed build:
https://github.com/RadoBuransky/scala-struct
The script ./gradle assemble is run as part of the install section of your build, it's the default.
If you want to skip this step, you can override it like so:
install: true
Docs: https://docs.travis-ci.com/user/customizing-the-build/#Skipping-the-Installation-Step
Related
I cannot make the gradle incremental feature work on a bitbucket pipeline with multiple steps.
What I like to have is:
A step that compile the code
A step that test the code being compiled (without a need to recompile)
Reading the doc I added the build folder and even the .gradle folder as artifacts of the compile step:
default:
- step:
name: Compile the application
caches:
- gradlew
script:
- ./gradlew core:compileJava
artifacts:
- .gradle/**
- build/**
- step:
name: Run the unit tests
caches:
- gradlew
script:
- ./gradlew core:test
Using the find command I can see the compiled classes and the .gradle files
into the unit test step.
However the unit test step always rerun the compilation process and using the -i option it outputs:
Task ':core:compileJava' is not up-to-date because:
Output property 'options.generatedSourceOutputDirectory' file /opt/atlassian/pipelines/agent/build/core/build/generated/sources/annotationProcessor/java/main has been removed.
Output property 'options.headerOutputDirectory' file /opt/atlassian/pipelines/agent/build/core/build/generated/sources/headers/java/main has been removed.
This seems like a trivial setup am I doing something wrong?
I have a test project that is built with Maven (Java). I can either execute the test from IntelliJ manually or from the command line by writing mvn test.
I put the project on CircleCI and it generated a yml file. And it was able to execute the tests on pipelines as well without any issue at first
Then I made something stupid. Initially tests were in this root: src/main/java/api/test. But I decided to move the test class to this root: src/test/java/api.
I did this change because src/test/java was the actual test folder created automatically when you create a Maven project. (The other test folder was created by me manually so I thought this was not the best practice and therefore decided to move the test class to src/test/java. Basically what I did is, I created a package named api under src/test/java and moved the test class to this package. After that I deleted src/main/java/api/test as it is empty now.
After this change, I didn't observe any issue. I could still run the tests from IntelliJ or from the command line by mvn test command. But after I commit my changes, I just checked the pipelines and saw this:
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.793
My project is still built and tested on CircleCI but it obviously does not execute the test class. I dont know why it is happening. I checked the yml file and there is nothing related with paths and it was working before. Here is my yml file:
# Use the latest 2.1 version of CircleCI pipeline process engine.
# See: https://circleci.com/docs/2.0/configuration-reference
version: 2.1
jobs:
# Below is the definition of your job to build and test your app, you can rename and customize it as you want.
build-and-test:
# These next lines define a Docker executor: https://circleci.com/docs/2.0/executor-types/
# You can specify an image from Dockerhub or use one of our Convenience Images from CircleCI's Developer Hub.
# Be sure to update the Docker image tag below to openjdk version of your application.
# A list of available CircleCI Docker Convenience Images are available here: https://circleci.com/developer/images/image/cimg/openjdk
docker:
- image: cimg/openjdk:11.0
steps:
# Checkout the code as the first step.
- checkout
# Use mvn clean and package as the standard maven build phase
- run:
name: Build
command: mvn -B -DskipTests clean package
# Then run your tests!
- run:
name: Test
command: mvn test
workflows:
# Below is the definition of your workflow.
# Inside the workflow, you provide the jobs you want to run, e.g this workflow runs the build-and-test job above.
# CircleCI will run this workflow on every commit.
# For more details on extending your workflow, see the configuration docs: https://circleci.com/docs/2.0/configuration-reference/#workflows
sample:
jobs:
- build-and-test
As I said the same yml file was working fine before I moved the test class. Now it probably can not locate my test file. What could be the problem here and how can I solve this? Any help is appreciated.
I've started a new project of SprintBoot and Kotlin and I wanted to use Travis-CI as my CI server.
I also wanted to use codecov to collect the reports about my code coverage
Everything seems to work perfectly beside one thing, My project currently is an empty SpringBoot project that contains (and no tests) and the build itself takes up to 2m (mostly due to the time it takes to install Gradle).
I checked on their site and saw some optimizations to the build, but they're looked to early for this stage of the project (e.g. parallel tests execution).
Am I missing something? is 2m is the baseline for Travis-CI building time?
My current configurations for Travis :
# This enables the 'defaults' to test java applications:
language: java
# We can specify a list of JDKs to be used for testing
# A list of available JDKs in Trusty can be seed in:
# https://docs.travis-ci.com/user/reference/xenial/#jvm-clojure-groovy-java-scala-support
jdk:
- openjdk11
before_script:
# makes sure that gradle commands can be executed on build
- chmod +x gradlew
script:
# Makes sure that gradle can be executed.
- ./gradlew check
# Generates the reports for codecov
- ./gradlew jacocoTestReport
# This is to enable CodeCov's coverage
# If a build is successful, the code is submitted for coverage analysis
after_success:
- bash <(curl -s https://codecov.io/bash)
You'll want to cache to improve speeds of your build on Travis. Gradle has a dedicated guide on building on Travis: https://guides.gradle.org/executing-gradle-builds-on-travisci/
For caching, scroll down to Enable caching of downloaded artifacts
I have an application in springboot which uses gradle to build the code.
I have setup https://github.com/gabrie-allaigre/sonar-gitlab-plugin on SonarQube and have integrated gitlab CI
to analyse code on every push/commit. What I want to achieve is to break the push/commit if the analysis fails.
Below is my .gitlab-ci.yml
image: XXXXXX:oraclejdk:1.8.0_121
before_script:
- export GRADLE_USER_HOME=`pwd`/.gradle
sonarqube_master_job:
stage: test
only:
- master
- release2.0
script:
- ./gradlew assemble
- ./gradlew -x test sonarqube -Dsonar.host.url=http://sonarqube.XXX.XXX.XXX:9000/sonarqube -Dsonar.login=xxxxxxxxxxxxxxxxxxxx
sonarqube_preview_feature_job:
stage: test
only:
- /^feature\/*/
- development
script:
- git checkout $CI_COMMIT_REF_NAME
- git merge --no-commit --no-ff
- ./gradlew assemble
- ./gradlew -x test sonarqube -Dsonar.host.url=http://XXXX.XXXXX.com:9000/sonarqube -Dsonar.login=xxxxxxxxxxxxxxxxxxxxx -Dsonar.analysis.mode=preview -Dsonar.gitlab.commit_sha=$CI_COMMIT_REF -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.gitlab.project_id=$CI_PROJECT_ID --stacktrace
How do I make sure the push fails if the analysis fails? Do I need to use webhooks. Is there a sample CI file?
#jibsonline, You can refer to my answer provided in the below link.
However the script answers only how to break the build on sonar analysis and display the results.
How to integrate Sonar Quality Gates with Gitlab-CI
Since gitlab triggers the build, once the changes were pushed, it is not advisable to set up an automated tool to revert the code changes on your behalf. Whenever a build fails, write script (dependencies) such that the code will not be deployed. Since the code is not deployed, your environment will not be effected. Also,set up an email configuration whenever build fails.
Example output for a normal build on Travis CI using Gradle:
https://travis-ci.org/2m/gradle-travis-test/builds/8579228
Gradle seems to think that the console has the same capabilities as a normal ANSI console, while in reality it only supports some of those features. Specifically, it seems to support colors, but not updating/replacing text (it's append-only).
How can I tell Gradle to use "plain" console output?
Gradle automatically detects the terminal type based on the $TERM environment variable (and a few other layers in between). Setting TERM=dumb causes Gradle to use plain console output.
In your .travis.yml file, you should now have something like the following (assuming the Gradle wrapper is used):
install:
- TERM=dumb ./gradlew assemble
script:
- TERM=dumb ./gradlew check
For sample output, see this build:
https://travis-ci.org/embarkmobile/zxing-android-minimal/builds/9639517
The solution of Ralf stopped working for me. Instead I'm now doing:
env:
- TERM=dumb
script:
- ./gradlew assemble -x test