I have a Scala project on GitHub and I use the Travis CI to build it and show the resulting badge on the project home in GitHub. I started to write unit tests and I realized that during one of my commit, some tests failed. But the travis build shows that the build passes.
I know that I should be using some kind of hook to check for tests failures and correspondingly fail my build. But I just don't know what the correct command for that is? I could not as well infer this from any documentation.
Here is my travis.yml file:
language: scala
jdk:
- oraclejdk8
scala:
- 2.11.7
script:
- sbt clean coverage test coverageReport
after_success:
- bash <(curl -s https://codecov.io/bash)
What hook should I add here so that the build fails as soon as one of my unit test fails?
Related
I have a project on GitHub where I'm using Travis CI for doing CI & CD. It is a Scala application built using sbt and runs as a web app using the Play framework. I have written the build pipeline such that I do the following as build stages:
jobs:
include:
- stage: test
script: sbt clean coverage test coverageReport
- stage: assemble-jar
script: sbt "set test in assembly := {}" assembly
if: branch = master
- stage: push-docker
script: bash docker_push.sh
if: branch = master
The problem that I face now is that during the test stage, it gets formatted and compiled once and so does it during the assembly and once again during the push-docker stage. This is quite annoying given the fact that how slow the Scala compiler is. Is there any way to optimize this such that it does not get compiled for every single stage? I did learn about caches and have the following as well in my yml:
cache:
directories:
- "$HOME/.ivy2/cache"
- "$HOME/.sbt"
But that unfortunately does not help as it caches only the dependencies but not the result of the previous build stage. What could I do to make it better?
First, you cannot really re-use the compiled class files of the test stage, since these have scoverage instrumentation embedded which makes them depend on scoverage at runtime. It will crash when you try to run without it.
Second, if you want to share build files between the assemble-jar and push-docker stages, you may use S3 to do so: https://docs.travis-ci.com/user/build-stages/share-files-s3/
Scala's sbt has the option to run only tests that previously failed. Is there a gradle equivalent?
https://www.scala-sbt.org/1.x/docs/Testing.html#testQuick
gradle does this automatically with all update-to-date tests marked as such, based on code changes since latest test passing.
You can also force re-run of tests if need be: How to run Gradle test when all tests are UP-TO-DATE?
I am trying to merge two modules into single module. Both are successfully running modules. I merge two modules. And trying to run the test cases.
i am compiling source and testcases by using sbt commands:
sbt
clean
compile
project module-read
test:compile
it:test
Till test:compile everything working fine but after it:test, it showing lot of compilation issues.
Could I know best way of compiling?
The test:compile task will only compile tests within the src/test/scala folder as per the default sbt test configuration.
In order to compile your integration tests (in src/it/scala) you will have to run it:compile .
See http://www.scala-sbt.org/0.13.5/docs/Detailed-Topics/Testing.html#integration-tests for more info.
Where can I override the repo URL that SBT uses to fetch its launcher when the SBT instance is provided by Travis-CI?
http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.8/sbt-launch.jar is currently giving 404s and, as a result, the builds are failing on Travis with:
$ sbt clean dependencyUpdates coverage test coverageReport
Detected sbt version 0.13.8
Downloading sbt launcher for 0.13.8:
From http://typesafe.artifactoryonline.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.8/sbt-launch.jar
To /home/travis/.sbt/launchers/0.13.8/sbt-launch.jar
Download failed. Obtain the jar manually and place it at /home/travis/.sbt/launchers/0.13.8/sbt-launch.jar
I ran into the same problem today, and logged an issue for travis-ci: https://github.com/travis-ci/travis-ci/issues/4527
As a workaround, you can download the sbt-launcher.jar by adding a before_script section to your .travis.yml
before_script:
- mkdir -p $HOME/.sbt/launchers/0.13.8/
- curl -L -o $HOME/.sbt/launchers/0.13.8/sbt-launch.jar http://dl.bintray.com/typesafe/ivy-releases/org.scala-sbt/sbt-launch/0.13.8/sbt-launch.jar
We just deployed the fix to production. SBT builds should be working now.
Sorry for the inconvenience.
https://github.com/travis-ci/travis-ci/issues/4527#issuecomment-124123880
For SonarQube jobs in Jenkins we'd like to proceed even though some tests might fail. Currently the Sonar Runner is not kicked off, because a test fails.
In Maven you'd just add -DtestFailureIgnore = true, but I cannot find anything similar for SBT.
I did find a onFailure thing for sbt, but have not found any examples anywhere how to use this. Could this be used to ignore test failures so the build job continues so the Sonar Runner gets started afterwards?
Or is there a setting in Jenkins to ignore the result of the build?
We use 'sbt clean coverage test coverageReport' as build command and have Sonar Runner in a post-build step.
Finally found a solution myself.
In SBT you can define a new task A which captures the result of another task B. This dependency ensures that task B is run when the new task A is started. By capturing the result, the result of task B is not the result of task A so if B fails, A does not (have to) fail.
So in this case, I added created a new 'ciTests' tasks to the 'build.sbt'
// Define a special test task which does not fail when any test fails,
// so sequential tasks (like SonarQube analysis) will be performed no matter the test result.
lazy val ciTests = taskKey[Unit]("Run tests for CI")
ciTests := {
// Capture the test result
val testResult = (test in Test).result.value
}
Now in the Jenkins job it build the project using SBT with commands (using SCoverage SBT plugin):
update coverage ciTests coverageReport
This build will succeed ignoring any failing tests. Therefore a next build step to start SonarRunner will start the analysis of the Scala project and put the results in SonarQube.
Thanks to #hugo-zwaal for pointing me to this answer which helped me solving my issue.