sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Szabolcs Vasas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SQOOP-3289) Add .travis.yml
Date Tue, 27 Feb 2018 19:43:00 GMT

    [ https://issues.apache.org/jira/browse/SQOOP-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379181#comment-16379181

Szabolcs Vasas commented on SQOOP-3289:

Hi [~dvoros],

Thank you for raising this JIRA and bringing up this topic!
I have also experimented with Travis recently it's a great chance to share our thoughts on

TL;DR: +1 for the patch, I think it can make the life of the contributors easier and it is
a good start for further improvements.


I think the benefit of Travis over Jenkins is that the contributors can run it on their own
forks and can get very quick feedback (the dependency caching minimizes the time spent with
the ivy resolve).
I understand your patch addresses this use case only but we can talk about how we want/could
extend it in the future.

I like that Travis integrates well with Github and pull requests so if we want to use pull
requests instead of review board enabling Travis on Sqoop trunk could simplify the review
process. I also find it great that .travis.yml is part of the project so it is much easier
to change it and it is more transparent what is happening in the CI job. We might be able
to do the same with Jenkins but I am not really familiar with it and the permission restrictions
make it much harder to configure it.

One potential issue I can see is that Travis has a 50 minute timeout for the jobs (https://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts).
However the good thing is that we could parallelize our build and have separate jobs for our
unit tests, integration tests, MySQL tests, etc. under the same build (https://docs.travis-ci.com/user/speeding-up-the-build/#Parallelizing-your-builds-across-virtual-machines).
This requires having a much better test category definition (https://issues.apache.org/jira/browse/SQOOP-3104)
but it seems to be feasible to cover most of our test cases.
Another benefit is that Travis supports starting Docker containers in the build (https://docs.travis-ci.com/user/docker)
this could help us setup our Docker-based third party test infrastructure much easier.
I would like to continue experimenting with Travis, please let me know what you think about
the above and as always all the contributions are welcome.


> Add .travis.yml
> ---------------
>                 Key: SQOOP-3289
>                 URL: https://issues.apache.org/jira/browse/SQOOP-3289
>             Project: Sqoop
>          Issue Type: Task
>          Components: build
>    Affects Versions: 1.4.7
>            Reporter: Daniel Voros
>            Assignee: Daniel Voros
>            Priority: Minor
>             Fix For: 1.5.0
> Adding a .travis.yml would enable running builds/tests on travis-ci.org. Currently if
you wish to use Travis for testing your changes, you have to manually add a .travis.yml to
your branch. Having it committed to trunk would save us this extra step.
> I currently have an example [{{.travis.yml}}|https://github.com/dvoros/sqoop/blob/93a4c06c1a3da1fd5305c99e379484507797b3eb/.travis.yml]
on my travis branch running unit tests for every commit and every pull request: https://travis-ci.org/dvoros/sqoop/builds
> Later we could add the build status to the project readme as well, see: https://github.com/dvoros/sqoop/tree/travis
> Also, an example of a pull request: https://github.com/dvoros/sqoop/pull/1

This message was sent by Atlassian JIRA

View raw message