December 11, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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.
|
December 11, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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.
|
December 11, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Roberts | 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 |
December 11, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
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. |
December 11, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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 |
December 11, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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. |
December 13, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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. |
December 13, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to ZombineDev | 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 |
December 13, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to ZombineDev | 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 |
December 13, 2014 Re: Travis-CI support for D | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin Nowak | 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?
|
Copyright © 1999-2021 by the D Language Foundation