2

I want to contribute to an open-source project (specifically, this one) where the project owner has already set up Travis. I want to integrate Coveralls to this project and send a pull-request. When I own the project, the process is simple:

  • Configure build/test system with .travis.yml and language specific tools
  • Take repoToken from Coveralls
  • Add repoToken as environment variable to project's Travis system
  • Add language specific configuration to .travis.yml's after_success cycle.

However, I've got problems with that when I do not own the repository.

  • Since I do not own the repository, I only can add project on Coveralls with my fork copy. What I mean is, my fork's coverage URL will be /github/myusername/forkedrepo in Coveralls and when I sent that PR to repository owner, it will be the same whereas it must be /github/ownersusername/originalrepo.
  • I cannot add environment variable repoToken to owner's Travis build system since I do not own it.

So my questions are:

  • Is it possible to automatize this process? Like merging my forked Travis system to owner's original system for repoToken environment variable and/or creating a Coveralls system for owner?
  • Or should I simply contact the owner, create separate Travis/Coveralls for my forked project by myself and leave some to-dos in codebase so that he can find these and change later?

Thanks in advance.


Environment

  • Java
  • Maven
  • Covertura Maven Plugin for coverage
  • Coveralls Maven Plugin for sending coverage results to Coveralls
Eray Erdin
  • 2,633
  • 1
  • 32
  • 66

1 Answers1

2

You might want to modify your own pom.xml according to the coverage tool you'd like to use see https://github.com/trautonen/coveralls-maven-plugin for some explanation.

You can avoid to put the repo token in the pom.xml file that you publish on github!

Instead you can run the coverage report from the command line.

Here is a small helper script that will allow to run converalls from the command line. Just put your token in a place like $HOME/.coveralls or any similar location.

#!/bin/bash
# WF 2019-06-26
# create test coverage report for coveralls
tokenpath=$HOME/.coveralls/coveralls.token
if [ ! -f $tokenpath ]
then
  echo "Script needs coveralls token in $tokenpath to work" 1>&2
  echo "Script can only be run successfully by project admins" 1>&2
  echo "see https://github.com/trautonen/coveralls-maven-plugin" 1>&2
  exit 1
else
  token=$(cat $tokenpath)
  # comment out to use jacoco
  #mvn clean test jacoco:report coveralls:report -D jacoco=true -DrepoToken=$token
  # comment out to use cobertura
  mvn cobertura:cobertura coveralls:report -DrepoToken=$token
fi

Update Here is a version using the COVERALLS_TOKEN environment variable:

#!/bin/bash
# WF 2019-06-26
# create test coverage report for coveralls

# is the environment variable not set?
if [ "$COVERALLS_TOKEN" = "" ]
then
  tokenpath=$HOME/.dukes/coveralls.token
  if [ ! -f $tokenpath ]
  then
    echo "Script needs coveralls token in $tokenpath to or COVERALLS_TOKEN environment variable to work" 1>&2
    echo "Script can only be run successfully by project admins" 1>&2
    echo "see https://github.com/trautonen/coveralls-maven-plugin" 1>&2
    echo "see https://stackoverflow.com/a/56815300/1497139" 1>&2
    exit 1
  fi
else
  export COVERALLS_TOKEN=$(cat $tokenpath)
fi
# the jacoco variable tries triggering a profile - check your pom.xml
# for any profile being in use
mvn clean test jacoco:report coveralls:report -D jacoco=true
#mvn clean test jacoco:report coveralls:report -D jacoco=true -DrepoToken=$token
#mvn cobertura:cobertura coveralls:report
#mvn cobertura:cobertura coveralls:report -DrepoToken=$COVERALLS_TOKEN
Wolfgang Fahl
  • 15,016
  • 11
  • 93
  • 186
  • 1
    Wow, I have really forgotten about *this question*. It's been a year, I think and I know how to do this, but since I forgot this question, I haven't written an answer here. | By the way, if you add `COVERALLS_TOKEN` to environment variables, you do not have to put `-DrepoToken` to args. Actually, it is much safer to do it with environment variables because CI platforms can obscure sensitive data such as tokens from build logs in (especially open source) projects. – Eray Erdin Jun 29 '19 at 13:23