Moaz Reyad commented on SINGA-488:

I found the reason of this problem. The _git_url_ is defined 

git_url: https://github.com/apache/incubator-singa.git

This will force the conda build command to always use the Apache master branch, 
even if the command is used from Travis CI to test a pull request on the Apache 
repository or on another forked repository. 

I think we should not use conda in the C++ continuous integration tasks. The 
C++ CI should be done with _cmake_ and _make test_. Conda can be used in 
another CI tasks for Python, but with the _source_ defined to build the current 
checked out code instead of always using the fixed URL of Apache master branch.

> Travis CI always build from Apache master branch
> ------------------------------------------------
>                 Key: SINGA-488
>                 URL: https://issues.apache.org/jira/browse/SINGA-488
>             Project: Singa
>          Issue Type: Bug
>            Reporter: Moaz Reyad
>            Priority: Blocker
> It seems that the Travis build always use the master branch from 
> github.com/apache/incubator-singa.git instead of building the pull request.
> When checking the job log of Travis, I found it reads from github two times:
> 1. In the first time, it reads the correct pull request: (for example Pull 
> Request 532)
> {code:bash}
> git clone --depth=50 https://github.com/apache/incubator-singa.git 
> apache/incubator-singa
> ...
> git fetch origin +refs/pull/532/merge:
> git checkout -qf FETCH_HEAD
> {code}
> 2. Then it ignores this correctly fetched code, and does another git clone 
> from the conda build script:
> {code:bash}
> Cloning into bare repository 
> '/home/travis/conda-bld-1594.2/git_cache/github.com/apache/incubator-singa.git'...
> ...
> Your branch is up to date with 'origin/master'.
> {code}
> This means that it always builds the master branch instead of building the 
> pull request. So it has two problems:
>  # Missed alarms: if the master branch builds successfully, this will be 
> shown as if the pull request is fine and can be merged. While the pull 
> request code was actually never built.
>  # False alarms: if the master branch does not build successfully, this will 
> be shown as if the pull request has a problem, even if the problem is 
> actually in the master branch not in the pull request.
> If this issue is correct, then this is a blocker issue and I suggest to 
> resolve it before creating or merging any pull request. Because the 
> continuous integration tools that is supposed to test the pull requests is 
> not working correctly.

This message was sent by Atlassian Jira

Reply via email to