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.

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.

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

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.

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

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.

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.

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

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

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?