www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Travis-CI support for D

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Glad to announce that D support on Travis-CI was launched today.

http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/

You can now get out-of-the-box continuous integration for your D 
projects on github. If you are already using dub, using Travis-CI is as 
simple as adding a 2 line .travis.yml file to your repo and toggling a 
switch on travis-ci.org.

language:d
sudo: false

You can also chose a specific compiler by adding a d: tag.

d: ldc-0.14.0

Build matrices are supported as well, so you can test your project 
against multiple compilers. Please only test as many compilers as you 
actually need!

d:
   - dmd-2.066.1
   - gdc-4.9.0
   - ldc-0.14.0

The following compilers were successfully tested.

dmd-2.064
dmd-2.065.0
dmd-2.066.1
gdc-4.8.2
gdc-4.9.0
ldc-0.13.0
ldc-0.14.0

Read the docs for more details http://docs.travis-ci.com/user/languages/d/.

And you can also have a look at these 2 libraries.

https://travis-ci.org/MartinNowak/hyphenate
https://travis-ci.com/MartinNowak/bloom

Happy testing
-Martin
Dec 10 2014
next sibling parent Adil Baig via Digitalmars-d-announce writes:
This is excellent! Well done guys!

On Thu, Dec 11, 2014 at 10:20 AM, Martin Nowak via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-
 language-support-comes-to-travis-ci/

 You can now get out-of-the-box continuous integration for your D projects
 on github. If you are already using dub, using Travis-CI is as simple as
 adding a 2 line .travis.yml file to your repo and toggling a switch on
 travis-ci.org.

 language:d
 sudo: false

 You can also chose a specific compiler by adding a d: tag.

 d: ldc-0.14.0

 Build matrices are supported as well, so you can test your project against
 multiple compilers. Please only test as many compilers as you actually need!

 d:
   - dmd-2.066.1
   - gdc-4.9.0
   - ldc-0.14.0

 The following compilers were successfully tested.

 dmd-2.064
 dmd-2.065.0
 dmd-2.066.1
 gdc-4.8.2
 gdc-4.9.0
 ldc-0.13.0
 ldc-0.14.0

 Read the docs for more details http://docs.travis-ci.com/user/languages/d/
 .

 And you can also have a look at these 2 libraries.

 https://travis-ci.org/MartinNowak/hyphenate
 https://travis-ci.com/MartinNowak/bloom

 Happy testing
 -Martin
Dec 10 2014
prev sibling next sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 11 December 2014 at 14:50, Martin Nowak via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/

 You can now get out-of-the-box continuous integration for your D projects on
 github. If you are already using dub, using Travis-CI is as simple as adding
 a 2 line .travis.yml file to your repo and toggling a switch on
 travis-ci.org.

 language:d
 sudo: false

 You can also chose a specific compiler by adding a d: tag.

 d: ldc-0.14.0

 Build matrices are supported as well, so you can test your project against
 multiple compilers. Please only test as many compilers as you actually need!

 d:
   - dmd-2.066.1
   - gdc-4.9.0
   - ldc-0.14.0

 The following compilers were successfully tested.

 dmd-2.064
 dmd-2.065.0
 dmd-2.066.1
 gdc-4.8.2
 gdc-4.9.0
 ldc-0.13.0
 ldc-0.14.0

 Read the docs for more details http://docs.travis-ci.com/user/languages/d/.

 And you can also have a look at these 2 libraries.

 https://travis-ci.org/MartinNowak/hyphenate
 https://travis-ci.com/MartinNowak/bloom

 Happy testing
 -Martin
So cool! I've been doing this manually for some time. What about those of us who don't/can't use dub?
Dec 10 2014
next sibling parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Thursday, 11 December 2014 at 06:02:13 UTC, Manu via 
Digitalmars-d-announce wrote:
 So cool! I've been doing this manually for some time.
 What about those of us who don't/can't use dub?
That's a good question. I have been using d-apt until now, but that only works for DMD.
Dec 10 2014
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
 So cool! I've been doing this manually for some time.
 What about those of us who don't/can't use dub?
Read the docs for more details ;). Just use make or whatever fits your bill. http://docs.travis-ci.com/user/languages/d/
Dec 11 2014
prev sibling next sibling parent reply Andrej Mitrovic via Digitalmars-d-announce writes:
On 12/11/14, Martin Nowak via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip
 ~/dmd.zip
It seems a bit of a waste of bandwidth to re-download the release for each run? Also, this will likely skew download statistics for us.
Dec 10 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 11 December 2014 at 07:40:14 UTC, Andrej Mitrovic 
via Digitalmars-d-announce wrote:
 On 12/11/14, Martin Nowak via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched 
 today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip
 ~/dmd.zip
It seems a bit of a waste of bandwidth to re-download the release for each run?
Indeed, and we'll have to see how that works. Easiest solution would be to add a caching proxy on either side (incapsula?). We could also come up with some chef recipes to preinstall a bunch of compilers on certain worker boxes.
 Also, this will likely skew download statistics for us.
Thought of that ;), I prepended Travis-CI to the curl user agent, so it will be easy to filter out this traffic. https://github.com/travis-ci/travis-build/commit/43286a1bf3865977461c3cb86882a8c35a964a9e
Dec 11 2014
parent reply Brad Roberts via Digitalmars-d-announce writes:
On 12/11/2014 3:16 AM, Martin Nowak via Digitalmars-d-announce wrote:
 On Thursday, 11 December 2014 at 07:40:14 UTC, Andrej Mitrovic via
 Digitalmars-d-announce wrote:
 On 12/11/14, Martin Nowak via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip
 ~/dmd.zip
It seems a bit of a waste of bandwidth to re-download the release for each run?
Indeed, and we'll have to see how that works. Easiest solution would be to add a caching proxy on either side (incapsula?). We could also come up with some chef recipes to preinstall a bunch of compilers on certain worker boxes.
For the last 30 days, travis represents about 2.5% of all downloads (1k of 40k). So, not horrible, but could also be a whole lot less (down from 1k to 74 based on January's data) if it were cached on each host.
Jan 27 2015
parent Paul O'Neil <redballoon36 gmail.com> writes:
On 01/27/2015 09:52 PM, Brad Roberts via Digitalmars-d-announce wrote:
 On 12/11/2014 3:16 AM, Martin Nowak via Digitalmars-d-announce wrote:
 On Thursday, 11 December 2014 at 07:40:14 UTC, Andrej Mitrovic via
 Digitalmars-d-announce wrote:
 On 12/11/14, Martin Nowak via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip
 ~/dmd.zip
It seems a bit of a waste of bandwidth to re-download the release for each run?
Indeed, and we'll have to see how that works. Easiest solution would be to add a caching proxy on either side (incapsula?). We could also come up with some chef recipes to preinstall a bunch of compilers on certain worker boxes.
For the last 30 days, travis represents about 2.5% of all downloads (1k of 40k). So, not horrible, but could also be a whole lot less (down from 1k to 74 based on January's data) if it were cached on each host.
I tried to use Travis a few weeks ago, but it's still on Ubuntu 12.04, so even though there is DMD 2.066.1, I can't get the other things I need. -- Paul O'Neil Github / IRC: todayman
Jan 27 2015
prev sibling next sibling parent reply Brad Roberts via Digitalmars-d-announce writes:
On 12/10/2014 11:34 PM, Andrej Mitrovic via Digitalmars-d-announce wrote:
 On 12/11/14, Martin Nowak via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip
 ~/dmd.zip
It seems a bit of a waste of bandwidth to re-download the release for each run? Also, this will likely skew download statistics for us.
Yes, it will. And bandwidth costs money. Please discuss with the travis-ci people how to cache that.
Dec 11 2014
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 11 December 2014 at 08:24:22 UTC, Brad Roberts via 
Digitalmars-d-announce wrote:
 On 12/10/2014 11:34 PM, Andrej Mitrovic via
 And bandwidth costs money.  Please discuss with the travis-ci 
 people how to cache that.
Yeah, I already asked, whether it's possible to cache that. I'll broach the subject again.
Dec 11 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Thursday, 11 December 2014 at 11:23:39 UTC, Martin Nowak wrote:
 On Thursday, 11 December 2014 at 08:24:22 UTC, Brad Roberts via 
 Digitalmars-d-announce wrote:
 On 12/10/2014 11:34 PM, Andrej Mitrovic via
 And bandwidth costs money.  Please discuss with the travis-ci 
 people how to cache that.
Yeah, I already asked, whether it's possible to cache that. I'll broach the subject again.
We could also provide chef recipes to preconfigure workers I guess, some other languages do that. But that's a lot of additional works when releasing new compiler versions, so I'd like to avoid that.
Dec 11 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
Nice, that I can finally get hold of you Brad. Need your help on 
three topics.

Cam we please rework the download folder structure? It's a PITA 
to work with, see 
https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91.
Most obvious idea, make a sub folder per version.
http://forum.dlang.org/post/mailman.2638.1417638975.9932.digitalmars-d puremagic.com

We need some sort of LATEST redirect, you cannot expect all 
downstream maintainers to update their scripts for each release.

And last we need dlang.org on the auto-tester. The documentation 
breaks with many pull requests. Just building would be enough for 
now, though it's a nice reward for people if they could see the 
result of their pull.

https://github.com/braddr/d-tester/issues/41

-Martin
Dec 11 2014
parent "Mathias LANG" <geod24 gmail.com> writes:
On Thursday, 11 December 2014 at 12:50:04 UTC, Martin Nowak wrote:
 Nice, that I can finally get hold of you Brad. Need your help 
 on three topics.

 Cam we please rework the download folder structure? It's a PITA 
 to work with, see 
 https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91.
 Most obvious idea, make a sub folder per version.
 http://forum.dlang.org/post/mailman.2638.1417638975.9932.digitalmars-d puremagic.com

 We need some sort of LATEST redirect, you cannot expect all 
 downstream maintainers to update their scripts for each release.

 And last we need dlang.org on the auto-tester. The 
 documentation breaks with many pull requests. Just building 
 would be enough for now, though it's a nice reward for people 
 if they could see the result of their pull.

 https://github.com/braddr/d-tester/issues/41

 -Martin
Brad, are we going to see this ? It could be VERY useful for some tools. Also, thank you Martin, Iain and David for this. It was really needed :)
Dec 18 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 11 December 2014 at 04:50:42 UTC, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
This is great! Thanks a lot.
Dec 11 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 11 December 2014 at 04:50:42 UTC, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/

 You can now get out-of-the-box continuous integration for your 
 D projects on github. If you are already using dub, using 
 Travis-CI is as simple as adding a 2 line .travis.yml file to 
 your repo and toggling a switch on travis-ci.org.

 language:d
 sudo: false

 You can also chose a specific compiler by adding a d: tag.

 d: ldc-0.14.0

 Build matrices are supported as well, so you can test your 
 project against multiple compilers. Please only test as many 
 compilers as you actually need!

 d:
   - dmd-2.066.1
   - gdc-4.9.0
   - ldc-0.14.0

 The following compilers were successfully tested.

 dmd-2.064
 dmd-2.065.0
 dmd-2.066.1
 gdc-4.8.2
 gdc-4.9.0
 ldc-0.13.0
 ldc-0.14.0

 Read the docs for more details 
 http://docs.travis-ci.com/user/languages/d/.

 And you can also have a look at these 2 libraries.

 https://travis-ci.org/MartinNowak/hyphenate
 https://travis-ci.com/MartinNowak/bloom

 Happy testing
 -Martin
This is awesome! I've got it working nicely on a few of my projects. Thanks.
Dec 11 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 11 December 2014 at 08:24, Brad Roberts via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On 12/10/2014 11:34 PM, Andrej Mitrovic via Digitalmars-d-announce wrote:
 On 12/11/14, Martin Nowak via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:
 Glad to announce that D support on Travis-CI was launched today.


 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
Awesome!! Btw, I've noticed this command in the log file of a Travis run: $ curl http://downloads.dlang.org/releases/2014/dmd.2.066.1.linux.zip
 ~/dmd.zip
It seems a bit of a waste of bandwidth to re-download the release for each run? Also, this will likely skew download statistics for us.
Yes, it will. And bandwidth costs money. Please discuss with the travis-ci people how to cache that.
+1 Though I'm not nearly getting anywhere near the transfer limit inplace on my VPS. So it's not something I worry about too much. Iain.
Dec 11 2014
parent "Martin Nowak" <code dawg.eu> writes:
On Thursday, 11 December 2014 at 12:52:40 UTC, Iain Buclaw via 
Digitalmars-d-announce wrote:
 Though I'm not nearly getting anywhere near the transfer limit 
 inplace
 on my VPS.  So it's not something I worry about too much.
Me neither on my servers, but he is right to worry about this and on S3 he actually has to pay for the traffic. Virtual host providers usually have a mixed calculation so the other customers are paying for you :o. Isn't LDC also S3 backed? Ah, github-cloud. Anyhow, there has already been a lot of automated traffic in the past, so if you didn't notice until now, that probably won't change soon. Also see http://forum.dlang.org/post/icoinkfyrmlnetxaoxxf forum.dlang.org. That's also a good opportunity to check your cache-control response headers. None of them actually allows HTTP proxy servers to cache your downloads. GDC: vibe.d's defaults => increase max-age to 31557600 and add public Last-Modified: Thu, 19 Jun 2014 07:55:26 GMT Etag: "F06035B41260515B28AD8924021AB57F" Expires: Fri, 12 Dec 2014 20:59:38 GMT Cache-Control: max-age=86400 DMD: no cache-control => add a Cache-Control header Last-Modified: Wed, 15 Oct 2014 21:10:57 GMT ETag: "dfb0833009f3204e850a87bbd560da03" LDC: github's default => add public Cache-Control: max-age=31557600 Content-Disposition: attachment; filename=ldc2-0.15.0-beta1-linux-x86_64.tar.xz Last-Modified: Fri, 14 Nov 2014 17:40:49 GMT ETag: "3322634a9958e6c959c8a70614d09818" https://code.google.com/p/doctype-mirror/wiki/ArticleHttpCaching#When_proxies_cache And there is always Incapsula, though I'm not sure whether they have an upper limit on the filesizes that they cache.
Dec 11 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-12-11 05:50, Martin Nowak wrote:

 Glad to announce that D support on Travis-CI was launched today.
Awesome, thanks for doing this. -- /Jacob Carlborg
Dec 11 2014
prev sibling next sibling parent reply "ZombineDev" <valid_email he.re> writes:
Thanks for the great work!

Is it possible to also include dmd+druntimie+phobos git-head?

It would be helpful to know if your project can be built with the 
new version of DMD (when it is officially released) ahead of 
time. If you are using some yet-to be deprecated code you can fix 
the issue much sooner and when the next version is released the 
migration cost would be virtually zero.
Sure, this won't be useful for everybody, but I am sure that for 
some larger organizations this will be helpful.
Also this will help test the new compiler and standard library 
code better, which should benefit everyone.

Git pulling and rebuilding dmd every time you update your project 
is not extremely efficient, but perhaps this can be done once a 
week. Or the autotester can upload the first binaries that pass 
all tests to some ftp in the beginning of every week.
I am not very familiar with Travis or the dmd release process, so 
correct me if I am wrong.
Dec 13 2014
next sibling parent "ZombineDev" <valid_email he.re> writes:
In the light of the DMD 2.066 regressions, I believe this would 
help bring the DMD release process closer to continuous delivery.

https://www.youtube.com/watch?v=IBghnXBz3_w
https://www.youtube.com/watch?v=igwFj8PPSnw
Dec 13 2014
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/13/2014 02:59 PM, ZombineDev wrote:
 Thanks for the great work!

 Is it possible to also include dmd+druntimie+phobos git-head?

 It would be helpful to know if your project can be built with the new
 version of DMD (when it is officially released) ahead of time. If you
 are using some yet-to be deprecated code you can fix the issue much
 sooner and when the next version is released the migration cost would be
 virtually zero.
 Sure, this won't be useful for everybody, but I am sure that for some
 larger organizations this will be helpful.
 Also this will help test the new compiler and standard library code
 better, which should benefit everyone.
There are some interesting points in here, but the implication that more people should test master is wrong, at least I hope so. 1. New releases should be pain-free Obviously new releases shouldn't introduce regressions. If there are new warnings/deprecations you should be able to live with them for a while and fix them when you have time. This is how we perceive this and if that doesn't work for you I'd be interested to know why. 2. master == unstable There are quite some newsgroup posts like "my project doesn't build with the latest dmd" or "latests dmd does A". That's not too helpful IMO, as it creates additional support overhead (deduplicating issues, answering, discussing). Therefor I wouldn't want to encourage this even more. If something breaks, go directly to bugzilla and file an issue. If you happen to know the cause go to github and add a comment on the relevant pull. New dmd and phobos code should be well tested and designed before we merge it into master. Things like std.experimental are supposed to deal with the lack of broad testing feedback during normal development. 3. Beta is for testing Alpha and beta releases are the right time to try a new release and they will be available on Travis-CI too [1]. During beta releases we're actively monitoring the dmd-beta mailing list [2] and are fixing any open regressions. This is the time when we're most receptive for newly reported issues. [1]: https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91 [2]: http://lists.puremagic.com/mailman/listinfo/dmd-beta
 Git pulling and rebuilding dmd every time you update your project is not
 extremely efficient, but perhaps this can be done once a week. Or the
 autotester can upload the first binaries that pass all tests to some ftp
 in the beginning of every week.
I was thinking about releasing nightlies every now and then. We can't really reduce the release cycle without massively changing our workflow. That doesn't seem worthwhile for the few core contributors that we are.
 I am not very familiar with Travis or the dmd release process, so
 correct me if I am wrong.
Done :) -Martin
Dec 13 2014
next sibling parent reply "ZombineDev" <valid_email he.re> writes:
I agree with most of your points. I don't think that anyone 
should consider master (git head) as even remotely stable. It's 
about testing experimental features in early stages of 
development. That said, I still think that more testing can't do 
any harm. Additionally, having pre-alpha releases (including 
installers and so on) available on a regular basis, should 
improve the release process.
Dec 13 2014
parent reply "ZombineDev" <valid_email he.re> writes:
Many successful software projects provide a way to get early, 
unstable versions if one desires to do so.
For example Firefox has 4 channels with corresponding levels of 
stability:
https://hacks.mozilla.org/2012/05/firefox-and-the-release-channels/
Dec 13 2014
parent "ZombineDev" <valid_email he.re> writes:
On Saturday, 13 December 2014 at 23:16:24 UTC, ZombineDev wrote:
 Many successful software projects provide a way to get early, 
 unstable versions if one desires to do so.
 For example Firefox has 4 channels with corresponding levels of 
 stability:
 https://hacks.mozilla.org/2012/05/firefox-and-the-release-channels/
Sorry, I missed that part of your reply: On Saturday, 13 December 2014 at 15:28:51 UTC, Martin Nowak wrote:
 I was thinking about releasing nightlies every now and then. We 
 can't really reduce the release cycle without massively 
 changing our workflow. That doesn't seem worthwhile for the few 
 core contributors that we are.
Dec 13 2014
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 14/12/2014 4:28 a.m., Martin Nowak wrote:
 On 12/13/2014 02:59 PM, ZombineDev wrote:
 Thanks for the great work!

 Is it possible to also include dmd+druntimie+phobos git-head?

 It would be helpful to know if your project can be built with the new
 version of DMD (when it is officially released) ahead of time. If you
 are using some yet-to be deprecated code you can fix the issue much
 sooner and when the next version is released the migration cost would be
 virtually zero.
 Sure, this won't be useful for everybody, but I am sure that for some
 larger organizations this will be helpful.
 Also this will help test the new compiler and standard library code
 better, which should benefit everyone.
There are some interesting points in here, but the implication that more people should test master is wrong, at least I hope so. 1. New releases should be pain-free Obviously new releases shouldn't introduce regressions. If there are new warnings/deprecations you should be able to live with them for a while and fix them when you have time. This is how we perceive this and if that doesn't work for you I'd be interested to know why. 2. master == unstable There are quite some newsgroup posts like "my project doesn't build with the latest dmd" or "latests dmd does A". That's not too helpful IMO, as it creates additional support overhead (deduplicating issues, answering, discussing). Therefor I wouldn't want to encourage this even more. If something breaks, go directly to bugzilla and file an issue. If you happen to know the cause go to github and add a comment on the relevant pull. New dmd and phobos code should be well tested and designed before we merge it into master. Things like std.experimental are supposed to deal with the lack of broad testing feedback during normal development. 3. Beta is for testing Alpha and beta releases are the right time to try a new release and they will be available on Travis-CI too [1]. During beta releases we're actively monitoring the dmd-beta mailing list [2] and are fixing any open regressions. This is the time when we're most receptive for newly reported issues. [1]: https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR91 [2]: http://lists.puremagic.com/mailman/listinfo/dmd-beta
 Git pulling and rebuilding dmd every time you update your project is not
 extremely efficient, but perhaps this can be done once a week. Or the
 autotester can upload the first binaries that pass all tests to some ftp
 in the beginning of every week.
I was thinking about releasing nightlies every now and then. We can't really reduce the release cycle without massively changing our workflow. That doesn't seem worthwhile for the few core contributors that we are.
 I am not very familiar with Travis or the dmd release process, so
 correct me if I am wrong.
Done :) -Martin
I'm also on the side of, we should get dmd, gdc and ldc nightlies available. As an early warning of issues instead of OMG it breaks fixxx itttttttttttt. Even though I don't use travis, I do think it would be a good thing to have. And anyway, it forces us to have good infrastructure going for automated releases.
Dec 13 2014
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/14/2014 01:42 AM, Rikki Cattermole wrote:
 And anyway, it forces us to have good infrastructure going for automated
 releases.
We already have that, I build that in Jan 2014.
Dec 14 2014
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 15/12/2014 5:03 a.m., Martin Nowak wrote:
 On 12/14/2014 01:42 AM, Rikki Cattermole wrote:
 And anyway, it forces us to have good infrastructure going for automated
 releases.
We already have that, I build that in Jan 2014.
Unless we have nightlies for e.g. installers, I'm not quite sure its going far enough. Although shouldn't be much of a stretch now (or atleast its not advertised anywhere).
Dec 14 2014
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/10/2014 08:50 PM, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.
I'm a noob when it comes to travis, so it isn't readily apparent to me, but given this, would travis support a build that installs a d compiler and also some version of python?
Dec 13 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-12-13 18:22, Ellery Newcomer wrote:

 I'm a noob when it comes to travis, so it isn't readily apparent to me,
 but given this, would travis support a build that installs a d compiler
 and also some version of python?
You can basically install whatever you want. Travis supports various languages, but that mostly means what is installed by default or installed automatically. -- /Jacob Carlborg
Dec 14 2014
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/13/2014 06:22 PM, Ellery Newcomer wrote:
 On 12/10/2014 08:50 PM, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.
I'm a noob when it comes to travis, so it isn't readily apparent to me, but given this, would travis support a build that installs a d compiler and also some version of python?
Read the docs, it cleary answers your questions. AFAIK a version of Python is preinstalled and yes this installs the D compiler you specify and dub. http://docs.travis-ci.com/
Dec 14 2014
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/10/2014 08:50 PM, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
trying it out with pyd, and I'm getting ImportError: libphobos2.so.0.66: cannot open shared object file: No such file or directory are shared libraries supported?
Dec 14 2014
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/14/2014 03:03 PM, Ellery Newcomer wrote:
 On 12/10/2014 08:50 PM, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/
trying it out with pyd, and I'm getting ImportError: libphobos2.so.0.66: cannot open shared object file: No such file or directory are shared libraries supported?
.. I'll take that as a no, then.
Dec 15 2014
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/15/2014 12:03 AM, Ellery Newcomer wrote:
 trying it out with pyd, and I'm getting

 ImportError: libphobos2.so.0.66: cannot open shared object file: No such
 file or directory

 are shared libraries supported?
Yes, shared libraries should work on linux. Check that you're respecting LD_LIBRARY_PATH. https://github.com/travis-ci/travis-build/pull/340/files#diff-ac986a81b67f1bd5851c535881c18abeR65
Dec 20 2014
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
It doesn't seem to work anymore, even http://lint.travis-ci.org/ 
says I can't use "language: d".

Atila

On Thursday, 11 December 2014 at 04:50:42 UTC, Martin Nowak wrote:
 Glad to announce that D support on Travis-CI was launched today.

 http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/

 You can now get out-of-the-box continuous integration for your 
 D projects on github. If you are already using dub, using 
 Travis-CI is as simple as adding a 2 line .travis.yml file to 
 your repo and toggling a switch on travis-ci.org.

 language:d
 sudo: false

 You can also chose a specific compiler by adding a d: tag.

 d: ldc-0.14.0

 Build matrices are supported as well, so you can test your 
 project against multiple compilers. Please only test as many 
 compilers as you actually need!

 d:
   - dmd-2.066.1
   - gdc-4.9.0
   - ldc-0.14.0

 The following compilers were successfully tested.

 dmd-2.064
 dmd-2.065.0
 dmd-2.066.1
 gdc-4.8.2
 gdc-4.9.0
 ldc-0.13.0
 ldc-0.14.0

 Read the docs for more details 
 http://docs.travis-ci.com/user/languages/d/.

 And you can also have a look at these 2 libraries.

 https://travis-ci.org/MartinNowak/hyphenate
 https://travis-ci.com/MartinNowak/bloom

 Happy testing
 -Martin
Jun 02 2015
next sibling parent "Alex Parrill" <initrd.gz gmail.com> writes:
On Tuesday, 2 June 2015 at 18:54:14 UTC, Atila Neves wrote:
 It doesn't seem to work anymore, even 
 http://lint.travis-ci.org/ says I can't use "language: d".

 Atila
Works for me, though the linter doesn't know about it.
Jun 02 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-02 20:54, Atila Neves wrote:
 It doesn't seem to work anymore, even http://lint.travis-ci.org/ says I
 can't use "language: d".
Works for me. Just tested it: https://travis-ci.org/jacob-carlborg/dstep/jobs/59055545 -- /Jacob Carlborg
Jun 02 2015
parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 2 June 2015 at 19:51:17 UTC, Jacob Carlborg wrote:
 On 2015-06-02 20:54, Atila Neves wrote:
 It doesn't seem to work anymore, even 
 http://lint.travis-ci.org/ says I
 can't use "language: d".
Works for me. Just tested it: https://travis-ci.org/jacob-carlborg/dstep/jobs/59055545
I don't know what happened. I copied your file and it started working. Probably a syntax error caused by the fact the linter was giving a false positive anyway. Atila
Jun 02 2015
parent reply "extrawurst" <stephan extrawurst.org> writes:
On Tuesday, 2 June 2015 at 20:46:09 UTC, Atila Neves wrote:
 On Tuesday, 2 June 2015 at 19:51:17 UTC, Jacob Carlborg wrote:
 On 2015-06-02 20:54, Atila Neves wrote:
 It doesn't seem to work anymore, even 
 http://lint.travis-ci.org/ says I
 can't use "language: d".
Works for me. Just tested it: https://travis-ci.org/jacob-carlborg/dstep/jobs/59055545
I don't know what happened. I copied your file and it started working. Probably a syntax error caused by the fact the linter was giving a false positive anyway. Atila
I remember the linter did not chew my config files either months ago, maybe it is not in-sync with the rest of the platform.. german wertarbeit
Jun 02 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-06-02 23:37, extrawurst wrote:

 I remember the linter did not chew my config files either months ago,
 maybe it is not in-sync with the rest of the platform.. german wertarbeit
Yeah, I remember testing the linter just when the D support was announced, it didn't work back then. -- /Jacob Carlborg
Jun 02 2015