I have a medium size github repository for which I configured Travis-CI/Coverity tools. About a month ago my setup had worked just fine: Travis compiled and built my application, and then performed the Coverity scan and I could see the results on my Coverity page.
However, lately, the Coverity analysis stopped working. I looked through the Travis log files and compared to the old logs when the builds were successful and that's what I found:
At the end of the log, the failed version contains the next warning:
[WARNING] No files were emitted. This may be due to a problem with your configuration or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at: /home/travis/build/name/repo-name/build/cov-int/build-log.txt
Extracting SCM data for 0 files...
...
So, the Travis builds are passing, but nothing is generated for the Coverity. I checked my Travis config file and it is identical to the commits when the Coverity builds were successful.
For the sake of experiment, I cloned my project repository, rolled back to the version when the builds were successful and set up Travis/Coverity for them. And guess what? Same warning! So, the identical setup that worked in the past (about 35 days ago), does not work anymore. Therefore, I make conclusion, something had changed on the part of Travis since it does not generate certain files.
I was wondering if anyone encountered this issue? and what it could be about? Are there some Travis settings I need to change?
Some additional info: I use CMake to build my project, and it has two dependencies: Qt and OpenSceneGraph (which I have to install for Travis).
This is the approximate script of my .travis.yml on my coverity_scan branch:
language: cpp
os: linux
compiler: gcc
sudo: required
dist: trusty
addons:
apt:
packages:
- cmake
- g++-4.8
coverity_scan:
project:
name: "name/project"
description: "Build submitted via Travis CI"
notification_email: email#domain.com
build_command: "make -j2 VERBOSE=1"
branch_pattern: coverity_scan
env:
global:
- PROJECT_SOURCE=${TRAVIS_BUILD_DIR}/src/
- PROJECT_BUILD=${TRAVIS_BUILD_DIR}/build/
# The next declaration is the encrypted COVERITY_SCAN_TOKEN, created
# via the "travis encrypt" command using the project repo's public key
- secure: "...secure..."
before_install:
# download Qt
# ...
# download OpenSceneGraph
# ...
# imitate x server
- export DISPLAY=:99.0
- /sbin/start-stop-daemon --start --quiet --pidfile /tmp/custom_xvfb_99.pid --make-pidfile --background --exec /usr/bin/Xvfb -- :99 -ac -screen 0 1280x1024x16
- sleep 3
install:
# install Qt
- sudo apt-get --yes install qt55base qt55imageformats qt55svg
# compiler
- export CXX="g++-4.8"
- export CC="gcc-4.8"
# install OpenSceneGraph
# ...
before_script:
# Qt location
# ...
# OpenSceneGraph variables
# ...
# create build folder
- mkdir $PROJECT_BUILD
- cd $PROJECT_BUILD
# cmake command
- cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH=/opt/qt54/lib/cmake -DProject_BUILD_TEST=ON -DProject_VERSION=0.0.0 $PROJECT_SOURCE
script:
- if [[ "${COVERITY_SCAN_BRANCH}" == 1 ]];
then
echo "Don't build on coverty_scan branch.";
exit 0;
fi
# compile everything, if not coverity branch
- make -j2
# run unit tests
# ...
After some research and looking through existing examples, I finally made it work. To fix the warning, and, therefore, to make sure files are emitted for the analysis, it is necessary to explicitly specify the compiler binary (updated according to the comment) . In my .travis.yml I had to add a build_command_prepend before the build_command of the coverity_scan add-on. An example of the final look for that block is as below:
# ...
coverity_scan:
project:
name: "name/project"
description: "Build submitted via Travis CI"
notification_email: name#domain.com
# ! have to specify the binary (updated, thanks to Caleb)
build_command_prepend: "cov-configure --comptype gcc --compiler gcc-4.8 --template"
build_command: "make VERBOSE=1"
branch_pattern: coverity_scan
# ...
Related
I'm trying to set up a CI for my .NET Core 3.1 class library. I created an account at https://travis-ci.org/github and selected my repository containing the code for my class library for a CI build.
Travis is successfully watching my master branch for commits, but I cannot get the CI build to succeed.
My repository: https://github.com/MintPlayer/MintPlayer.AspNetCore.SitemapXml
Target framework: .NET Core 3.1
My latest .travis.yml file:
language: csharp
mono: none
dotnet: 3.1.302
script:
- dotnet restore
dist: trusty
sudo: required
History of attempted travis.yml files (all failed):
But somehow this always errors, this time with the following output:
Clean output:
docker stop/waiting
resolvconf stop/waiting
C# support for Travis-CI is community maintained.
Please open any issues at https://travis-ci.community/c/languages/37-category and cc #joshua-anderson #akoeplinger #nterry
Installing .NET Core
$ export DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
$ export DOTNET_CLI_TELEMETRY_OPTOUT=1
E: Unable to locate package dotnet-sdk-3.1
E: Couldn't find any package by glob 'dotnet-sdk-3.1'
E: Couldn't find any package by regex 'dotnet-sdk-3.1'
The command "sudo apt-get install -qq dotnet-sdk-3.1=3.1.302*" failed and exited with 100 during .
Your build has been stopped.
Raw output: https://api.travis-ci.org/v3/job/709293291/log.txt
What's wrong with my travis.yml configuration. Why can't I CI test my class library with this config?
I mainly want to CI test for .NET Core. If mono could be included this would be very nice. All the examples you'd find in the git history are also examples that I digged up in other repositories.
You are using:
dist: trusty
That's Ubuntu 14.04.6 LTS which is not supported by .NET Core 3.1. Try a newer version of Ubuntu such as bionic.
This is also answered in the travis community post:
dotnet-sdk-3.0 is not available for Trusty (presumably because it’s EOL): https://packages.microsoft.com/ubuntu/14.04/prod/dists/trusty/main/binary-amd64/Packages Move to dist: xenial (which is the default so you can just omit it) or dist: bionic.
TLDR: Ensure to keep system OS up-to-date to help ensure consistency with current spec files.
Symptom
When rebuilding PostgreSQL 11.1 SRPM using mock, the build fails with:
BUILDSTDERR: /builddir/build/BUILD/postgresql-11.1/src/bin/psql/command.c:1814 undefined reference to `PQencryptPasswordConn`
NB: PQencryptPasswordConn is a libpq.so function (provided by postgresql-devel-10.3-5.fc27.x86_64 on my system...outside the mock chroot environment). Unless I'm mistaken, the Postgresql SRPM builds the postgresql-devel RPM along with others.
Steps to reproduce
I ran the following to rebuild the SRPM before attempting to apply any patches not already present in the SRPM:
# Obtain SRPM source
git clone https://src.fedoraproject.org/rpms/postgresql.git
cd postgresql
# Download local copies of SRPM sources
wget $(spectool -S *.spec | awk '/^Source.*:\/\//{IFS=" "; print $2}')
# ...check SHAs of downloaded sources...
# Run SRPM-specific prep scripts
./generate-pdf.sh
./generate-sources.sh
# Generate the SRPM
mock --root=fedora-27-x86_64 --resultdir="./SRPMS" --buildsrpm --spec postgresql.spec --sources .
# >>> Everything seems to work fine up to this point <<<
# Build the RPM inside mock chroot
mock --root=fedora-27-x86_64 --rebuild ./SRPMS/postgresql-11.1-4.fc27.src.rpm
# !!! Fail here (with symptom above) !!!
The Problem
I have so far been unable to have mock load the appropriate libpq library headers into the chroot environment to make sure rpmbuild builds against the libpq that contains the PQencryptPasswordConn header (which appears to exist on my system outside the build environment):
grep -lr "PQencryptPasswordConn" /usr/include
# /usr/include/libpq-fe.h
grep -lr "PQencryptPasswordConn" /var/lib/mock/fedora-27-x86_64/root/usr/include
# (Nothing returned)
When reviewing mock's installed_pkgs.log, the following were installed (the latter of which I expect would provide a version of libpq headers):
postgresql-libs-9.6.10-3.fc27.x86_64
postgresql-devel-9.6.10-3.fc27.x86_64
However, I cannot find a way to install the postgresql-* packages into the chroot environment that contain the updated library headers.
The Ask
Since postgresql SRPM is supposed to build postgresql-devel RPM, I think that mock will need to build and install the postgresql-devel RPM in the chroot before rpmbuild attempts to compile psql/command.c so that the latter compilation finds the appropriate library headers (unless the build process is intelligent enough to identify new libraries currently under build).
How can I best accomplish this (would prefer to avoid multiple mock calls for each RPM package built from the SRPM unless that's the only way to go)?
Please note that the build process on my system spawns multiple processes to parallel compilations.
I have also tried to use mockchain —recurse without success.
System Info
Linux 4.16.6-202.fc27.x86_64
First hint, you use the latest postgresql.spec version, but you try to build it against rather old (in fact unsupported nowadays) version 27 of Fedora distribution. I'd encourage you to migrate to a newer version of Fedora, or at least checkout the branch f27 in the same RPM git repository.
Second hint, we changed the layout of PostgreSQL packaging in Fedora 30+. We've cut out the library (libpq.so) into separate package, per announcement.
How to continue; always checkout appropriate branch based on what Fedora you build against, and adjust the spec file appropriately (checkout f27 and update to PostgreSQL 11.1 in this case).
JFTR (might help), there already is a testing modular build of PostgreSQL 11 against Fedora 28+, and the build scripts are maintained in separate branch stream-postgresql-11. With a bit of luck, you would be able to build that branch against old Fedora 27, too. Note that this version of postgresql.spec file is a little bit complicated (it needs to be because we build it against different versions of Fedora).
Can anyone suggest me a better documentation about spark-jobserver. I have gone through the url spark-jobserver but unable to follow the same. It will be great if some one explain step by step instruction on how to use spark-jobserver.
Tools used in building the project.
sbt launcher version 0.13.5
Scala code runner version 2.11.6
With the above mentioned tools I am getting errors while building the spark-jobserver.
The documentation provided in the jobserver repo is indeed confusing.
Here's the steps I followed to manually build and run Spark Job Server on a local machine.
1. git clone https://github.com/spark-jobserver/spark-jobserver
2. sudo mkdir -p /var/log/job-server
3. sudo chown user1:user1 /var/log/job-server
4. cd spark-jobserver
5. sbt job-server/assembly
6. cd config
7. cp local.sh.template abc.sh # Note that the same name 'abc' is used in steps 8 and 10 as well
8. cp ec2.conf.template abc.conf
9. cd .. # The jobserver root dir
10. ./bin/server_package.sh abc # This script copies the files and packages necessary to run job server into a single dir [ default - /tmp/job-server]
11. cd /tmp/job-server [This is where the files and packages necessary to run job server are published by default]
12. ./server_start.sh
13. Run ./server_stop.sh to stop the server
Hope this helps
Here are the steps that I used to install:
Clone the jobserver repo.
Get sbt using wget https://dl.bintray.com/sbt/native-packages/sbt/0.13.8/sbt-0.13.8.tgz
Move "sbt-launch.jar" in sbt/bin to /bin
Create a script /bin/sbt, contents found here, making sure to change the pointer to java if necessary
Make the above script executable
Now cd into the spark jobserver directory, and run sbt publish-local
Assuming the above was successful, run sbt in the same directory
Finally, use the command re-start, and if it succeeds the server is now running!
Is it possible to specify the minor version of the JDK for jobs running on Travis? I have a JavaFX project which is failing because JDK 1.8.0_31 is being used to perform the build where as the project uses some classes that were only shipped in Java 1.8.0_40 (specifically Alert and Spinner).
Currently my .travis.yml file looks like below:
language: java
jdk:
- oraclejdk8
Here's a link to the failed build just in case it's useful.
This solution based on apt addon works for me:
language: java
jdk:
- oraclejdk8
addons:
apt:
packages:
- oracle-java8-installer
In result I have java version "1.8.0_91". The solution source is here
I finally got it working. This solution is not really reccommended as it uses linuxbrew to install Oracle JDK 8.0_40. Thanks to zrcoder on Github I ended up with this .travis.yml:
language: java
branches:
only:
- master
notifications:
email: false
before_install:
- rm -rf ~/.linuxbrew
- yes | ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/linuxbrew/go/install)"
- export PATH="$HOME/.linuxbrew/bin:$PATH"
- export MANPATH="$HOME/.linuxbrew/share/man:$MANPATH"
- export INFOPATH="$HOME/.linuxbrew/share/info:$INFOPATH"
- brew install jdk
- export JAVA_HOME=/home/travis/.linuxbrew/Cellar/jdk/1.8.0-40
Although this works, Travis-CI should be updated by next month, so update your config for shorter build times.
I recommend using Travis CI's Trusty build environment which uses newer software than the default Precise environment. It's quicker and more reliable than redownloading the newest JDK on each build.
Just add the following to the top level of .travis.yml
dist: trusty
I have the current travis.yml on my Github:
# see http://about.travis-ci.org/docs/user/languages/php/ for more hints
language: php
# list any PHP version you want to test against
php:
# aliased to a recent 5.4.x version
- 5.4
# aliased to a recent 5.5.x version
- 5.5
All my jobs keep failing, but with a minimalistic build, i Cannot see why it fails.. As Travis doesn't exactly have the best information.. Here is the last few chunks of my logs:
Job 9.1:
$ git clone --depth=50 --branch=master git://github.com/SlayerSolutions/Authentication.git SlayerSolutions/Authentication
Cloning into 'SlayerSolutions/Authentication'...
remote: Counting objects: 128, done.
remote: Compressing objects: 100% (104/104), done.
remote: Total 128 (delta 55), reused 83 (delta 15)
Receiving objects: 100% (128/128), 19.17 KiB | 0 bytes/s, done.
Resolving deltas: 100% (55/55), done.
$ cd SlayerSolutions/Authentication
git.2
$ git checkout -qf 1df78d018dbe8a81e66490e90012229adcff7af8
$ phpenv global 5.4
$ php --version
PHP 5.4.16 (cli) (built: Jun 28 2013 11:14:20)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
$ composer --version
Warning: This development build of composer is over 30 days old. It is recommended to update it by running "/home/travis/.phpenv/versions/5.4.16/bin/composer.phar self-update" to get the latest version.
Composer version 7755564962718189d5d7d9fdee595283c8f032b7
$ phpunit
PHPUnit 3.7.21 by Sebastian Bergmann.
Usage: phpunit [switches] UnitTest [UnitTest.php]
phpunit [switches] <directory>
--log-junit <file> Log test execution in JUnit XML format to file.
...Bla,bla,bla
The command "phpunit" exited with 2.
Done. Your build exited with 1.
and Job 9.2:
Is the same and ends with:
The command "phpunit" exited with 2.
Done. Your build exited with 1.
So, what is going wrong here?
Any non-zero exit code of the scripts you run with Travis are considered a failure.
Your minimalistic .travis.yml does not specify a build script, therefore the default build script for PHP is run, which is phpunit (see also the documentation).
As you don't have a phpunit.xml in your repository, there is basically nothing to run for Travis. This leads to the failing build.
It really depends what you want to do with Travis, but either you configure your repository according to the default or define a script to execute when running the build like this:
language: php
php:
- 5.4
- 5.5
script: ./build.sh
Then you can specify whatever you want in the build.sh to be executed when running build.
You may need to insure that ./build.sh is executable which you can do with
before_install:
- chmod +x build.sh
You can also make the script bash build.sh or sh build.sh.