[
https://issues.apache.org/jira/browse/SINGA-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925529#comment-16925529
]
Moaz Reyad commented on SINGA-488:
----------------------------------
I found the reason of this problem. The _git_url_ is defined
[here|https://github.com/apache/incubator-singa/blob/master/tool/conda/singa/meta.yaml#L31]
as:
{code:bash}
git_url: https://github.com/apache/incubator-singa.git
{code}
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
(v8.3.2#803003)
