add Continuous Integration using TravisCI #268
Conversation
|
Can one of the admins verify this patch? |
1 similar comment
|
Can one of the admins verify this patch? |
|
Hope there is enough comments in Since As talked with @tbetcke by email, it should be better to deploy an internal CI service at UCL. But not sure that the effort will pay off. Moreover, this patch is currently doing the job for free : in term of maintenance, only one script to maintain, and in term of service, since all the tough work is externally done by the company Travis. Hope this is pushing in the right direction. |
|
@zimoun @ucl-rsd-ci is the bot user for the internal UCL Jenkins server |
|
thanks :-) if there is Jenkins, does it mean that Continuous Integration is supported by UCL ? especially build and test ? Because even if things are done well, it is still difficult to build/compile bempp, especially the dependencies. And sometimes, just an upgrade somewhere else breaks. Therefore, something is this flavor should be useful to help. |
|
Yes, CI is supported by UCL and BEM++ is built and tested there. Doesn't preclude travis though. Why not install boost, tbb, and Dune via atp-get though? |
|
Hi, using the binaries on the homepage installation on supported Ubuntu On 6 June 2016 at 13:04, mdavezac [email protected] wrote:
Dr. Timo Betcke |
|
Hi, the link to the dashboard is broken: Error 404. @mdavezac I have noticed that the version of the dependencies is sensible. For example, after my last update with Debian/testing, the version of boost was too high and then, the compilation failed with cryptic messages (from outside the project, it is hard to track why bempp fails to compile). Another example is the version 3.5 of CMake, on which we stayed stuck couple of days before be able to identify the issue. Therefore, I prefer letting bempp manage as dependencies as possible. Last, it should be useful to report in the install guide all the versions possibly auto downloaded by CMake (it will simplify the identification of the compilation issues ; I am currently opening time to time the CMakeLists to extract these version number, which is not really user friendly) |
|
Can one of the admins verify this patch? |
|
@tbetcke, as far as RSDG is concerned, using Travis for open-source projects is a good addition/alternative to the UCL Jenkins. |
|
@mdavezac @tbetcke That's why --from my point of view-- it should be useful for users to have a clear list about the dependencies and their version. Moreover, the For sure, if all the tough work is already done with Jenkins, then all the recipes used to build and all the log of these builds should be publicly exposed. It will help, at least me :-) I know it is out of topic (we should open another issue to talk about packaging), but I mention some work around |
|
Hi Zimoun,
thanks for those. We haven't decided about travis. It is not really a
priority at the moment as Jenkins works quite well.
Your conda recipe is very nice. I'd like to adopt it for our new version.
We have version 3.1 out now by the way. I haven't publicly advertised it
yet as we are finishing two papers that explain the
new functionality and we will publicise it together with the papers. 3.1 is
much better in terms of dependencies and
we have ppas for Ubuntu. You can find more info in the Bempp forum.
Best wishes
Timo
…On 16 January 2017 at 16:42, zimoun ***@***.***> wrote:
@mdavezac <https://github.com/mdavezac> @tbetcke
<https://github.com/tbetcke>
From my point of view of simple user, I was stucked several times with
compilation errors, and often with cryptic messages, i.e., hard to unknot
the issues (dependencies, versions, etc.).
That's why --from my point of view-- it should be useful for users to have
a clear list about the dependencies and their version. Moreover, the
.travis.yml exposes a full recipe that builds (or not), therefore it
provides a practical starting point. Last, but not least, it is more
transparent that the non-exposed current Jenkins.
For sure, if all the tough work is already done with Jenkins, then all the
recipes used to build and all the log of these builds should be publicly
exposed. It will help, at least me :-)
I know it is out of topic (we should open another issue to talk about
packaging), but I mention some work around conda that goes in this same
direction: expose full recipe that builds.
https://github.com/zimoun/bempp-conda
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#268 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAHNKIRoBGkrE0eYKqUr2b__bEl5mvBJks5rS53_gaJpZM4Ifc_3>
.
--
Dr. Timo Betcke
Reader in Mathematics
University College London
Department of Mathematics
E-Mail: [email protected]
Tel.: +44 (0) 20-3108-4068
Fax.: +44 (0) 20-7383-5519
|
|
Hi Timo, Feel free to extract all what you want about the Nice for this new version ! The new functionality, is it publicly pushed into the repo ? If yes, I could manage some time to update the conda recipe. Thank you to point me the PPA. However, I am not able to find the link. I know that the manpower is not infinite, and I am not currently able to evaluate the amplitude of the task, but I would like to write a clean Debian source package (if it is not already done for the ppa), maybe try to push it to their infrastucture. The issue concerns the dependencies; especially since you have patched some. We should open a new issue to talk about packaging ? |
Add short
.travis.yml, as example.This file is the recipe to automatically build the bempp code, using the external service TravisCI.
The service allows to build several branch, with different options (python 2.7, 3.5, etc.), and then to run the test suite.
For example, the
, which should be added in the
eg-travisbranch of the fork is built at each push and the indicator is given by this bullet:README.Moreover, options can be added, e.g., apply the build process at Pull-Request, etc.
This patch should add a quick view about the sanity of the project, and automatically report the issues of building (satisfied dependencies, etc.). Note that the external service TravisCI uses Ubuntu LTS (seems also possible to configure MacOS ?).
Hope this helps