www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - http://www.rust-ci.org/

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
This has been pointed out in the reddit thread - it's an automated 
platform that should make our betas much easier to work with. Thoughts?

Andrei
Feb 24 2014
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu 
wrote:

 This has been pointed out in the reddit thread - it's an 
 automated platform that should make our betas much easier to 
 work with. Thoughts?

 Andrei


Definitely. I've been thinking about setting up something like 
this (even if it's a simple shared Jenkins server to begin with), 
but I've been travelling a lot lately, so I haven't been able to 
set up any hardware.

Hopefully someone will be able to get the ball rolling on this 
shortly. I'll keep an eye out in case I can help with anything.
Feb 24 2014
parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 25 February 2014 at 01:42:24 UTC, Jakob Ovrum wrote:

 Definitely. I've been thinking about setting up something like 
 this (even if it's a simple shared Jenkins server to begin 
 with), but I've been travelling a lot lately, so I haven't been 
 able to set up any hardware.

 Hopefully someone will be able to get the ball rolling on this 
 shortly. I'll keep an eye out in case I can help with anything.


I have had plans to add automatic CI for code.dlang.org projects, 
got to the point where proof-of-concept was discussed with Sonke 
and have been distracted since than. Still can spare a single 
dedicated server for that.
Feb 25 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 24 Feb 2014 17:22:56 -0800, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 This has been pointed out in the reddit thread - it's an automated  
 platform that should make our betas much easier to work with. Thoughts?

 Andrei


I just want to point out that this will only work with Rust projects  
according to the info on the pages. However if you are speaking generally  
then this would be an absolutely fantastic addition to our build process  
and something that I've been asking for for a long time.

There are about a dozen tools out there that do this, but would it be  
worth investing more in the Auto-Tester to have it do the packaging? It  
already does the builds just fine. It could be taught to package and  
upload the latest binaries somewhere...

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 24 2014
prev sibling next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu 
wrote:

 This has been pointed out in the reddit thread - it's an 
 automated platform that should make our betas much easier to 
 work with. Thoughts?

 Andrei


I don't think it is a bad idea, but as pointed out this specific 
project is for Rust. We could set one up for D, but that would 
need machines and other labor. And as Walter said, we're already 
pushing the build machines 24/7.
Feb 24 2014
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/25/14, Jesse Phillips <Jesse.K.Phillips+D gmail.com> wrote:

 I don't think it is a bad idea, but as pointed out this specific
 project is for Rust. We could set one up for D, but that would
 need machines and other labor. And as Walter said, we're already
 pushing the build machines 24/7.


And building binaries is easy anywho. E.g.:
https://github.com/CyberShadow/Digger
Feb 25 2014
parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 25 February 2014 at 09:05:36 UTC, Andrej Mitrovic 
wrote:

 On 2/25/14, Jesse Phillips <Jesse.K.Phillips+D gmail.com> wrote:

 I don't think it is a bad idea, but as pointed out this 
 specific
 project is for Rust. We could set one up for D, but that would
 need machines and other labor. And as Walter said, we're 
 already
 pushing the build machines 24/7.


 And building binaries is easy anywho. E.g.:
 https://github.com/CyberShadow/Digger


I have started a section on the wiki to list similar tools:
http://wiki.dlang.org/Building_DMD#Existing_tools
Feb 25 2014
prev sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu 
wrote:

 This has been pointed out in the reddit thread - it's an 
 automated platform that should make our betas much easier to 
 work with. Thoughts?

 Andrei


I like the idea, but I think the first step would be to make sure 
D is officially support on Travis CI. Then start thinking about 
this.

--
/Jacob Carlborg
Feb 25 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 2/25/14, 9:48 AM, Jacob Carlborg wrote:

 On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu wrote:

 This has been pointed out in the reddit thread - it's an automated
 platform that should make our betas much easier to work with. Thoughts?

 Andrei


 I like the idea, but I think the first step would be to make sure D is
 officially support on Travis CI. Then start thinking about this.

 --
 /Jacob Carlborg


Why do you need official support on Travis CI to do that?
Feb 25 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-02-25 15:12, Ary Borenszweig wrote:


 Why do you need official support on Travis CI to do that?


I guess thought it would be easier to have a common way to do it.

-- 
/Jacob Carlborg
Feb 25 2014
prev sibling next sibling parent "Mathias LANG" <pro.mathias.lang gmail.com> writes:
On Tuesday, 25 February 2014 at 12:48:09 UTC, Jacob Carlborg 
wrote:

 On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei 
 Alexandrescu wrote:

 This has been pointed out in the reddit thread - it's an 
 automated platform that should make our betas much easier to 
 work with. Thoughts?

 Andrei


 I like the idea, but I think the first step would be to make 
 sure D is officially support on Travis CI. Then start thinking 
 about this.

 --
 /Jacob Carlborg


I strongly agree. Travis is already well established in the open 
source world, and integrates well with github, which is where 
most of D project are hosted AFAIK. Putting our effort to make 
Travis works with D smoothly will bring much more benefit, both 
in short and long term than creating yet another D-specific tool.
Note: Vibe.d is already using Travis.
Feb 25 2014
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Tuesday, 25 February 2014 at 12:48:09 UTC, Jacob Carlborg 
wrote:

 On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei 
 Alexandrescu wrote:

 This has been pointed out in the reddit thread - it's an 
 automated platform that should make our betas much easier to 
 work with. Thoughts?

 Andrei


 I like the idea, but I think the first step would be to make 
 sure D is officially support on Travis CI. Then start thinking 
 about this.

 --
 /Jacob Carlborg


It would be nice if it had an API available that didn't force you 
to use Travis.

For my own CI purposes, I use Bamboo with a D plugin I made and 
find it works quite nicely. In theory it could be quite simple 
for that to add integration with this system.
Feb 25 2014
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 25 Feb 2014 17:27:33 -0800, Kapps <opantm2+spam gmail.com> wrote:


 On Tuesday, 25 February 2014 at 12:48:09 UTC, Jacob Carlborg wrote:

 On Tuesday, 25 February 2014 at 01:22:57 UTC, Andrei Alexandrescu wrote:

 This has been pointed out in the reddit thread - it's an automated  
 platform that should make our betas much easier to work with. Thoughts?

 Andrei


 I like the idea, but I think the first step would be to make sure D is  
 officially support on Travis CI. Then start thinking about this.

 --
 /Jacob Carlborg


 It would be nice if it had an API available that didn't force you to use  
 Travis.

 For my own CI purposes, I use Bamboo with a D plugin I made and find it  
 works quite nicely. In theory it could be quite simple for that to add  
 integration with this system.


We use Bamboo at work and I like it quite a lot. Like all Atlassian  
products it's free for Open-Source projects and it comes with source code.  
It also has a very expansive REST API.

But I'm not opposed to any CI so long as it does what we need it to do.  
Mostly we just need CI. I still think that the Auto-Tester would be the  
path of least resistance on this...

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 25 2014
parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/25/14, 8:30 PM, Adam Wilson wrote:

 On Tue, 25 Feb 2014 17:27:33 -0800, Kapps <opantm2+spam gmail.com> wrote:

 We use Bamboo at work and I like it quite a lot. Like all Atlassian
 products it's free for Open-Source projects and it comes with source
 code. It also has a very expansive REST API.

 But I'm not opposed to any CI so long as it does what we need it to do.
 Mostly we just need CI. I still think that the Auto-Tester would be the
 path of least resistance on this...


The 'build' part of the auto-tester is the easiest part.  The majority 
of the logic is in what to build when and the user interface on top of 
that state.  None of that exists for this use case.  It's not hard 
logic, but it would need to be built.

This use case can likely also ignore the multi-platform part and stick 
to just building on one which simplifies the job significantly.  And it 
can also likely all be done on one box since it's likely that it can all 
be done in a relatively short period of time.

All that, in my mind, suggests that while it could be integrated into 
the auto-tester, it gains little in doing so and puts more work on my 
plate and more load on already loaded systems.  I think having a new 
volunteer involved would be more long term beneficial.

Later,
Brad
Feb 25 2014
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 25 Feb 2014 20:50:49 -0800, Brad Roberts <braddr puremagic.com>  
wrote:


 On 2/25/14, 8:30 PM, Adam Wilson wrote:

 On Tue, 25 Feb 2014 17:27:33 -0800, Kapps <opantm2+spam gmail.com>  
 wrote:

 We use Bamboo at work and I like it quite a lot. Like all Atlassian
 products it's free for Open-Source projects and it comes with source
 code. It also has a very expansive REST API.

 But I'm not opposed to any CI so long as it does what we need it to do.
 Mostly we just need CI. I still think that the Auto-Tester would be the
 path of least resistance on this...


 The 'build' part of the auto-tester is the easiest part.  The majority  
 of the logic is in what to build when and the user interface on top of  
 that state.  None of that exists for this use case.  It's not hard  
 logic, but it would need to be built.

 This use case can likely also ignore the multi-platform part and stick  
 to just building on one which simplifies the job significantly.  And it  
 can also likely all be done on one box since it's likely that it can all  
 be done in a relatively short period of time.

 All that, in my mind, suggests that while it could be integrated into  
 the auto-tester, it gains little in doing so and puts more work on my  
 plate and more load on already loaded systems.  I think having a new  
 volunteer involved would be more long term beneficial.

 Later,
 Brad


Well, in my CI experience at work you want to run CI on every platform  
your trying to support as each is a different environment, and the AT has  
access to all of them. As for system load, you wouldn't do this in the  
pull tester. I'd argue that use this would increase load somewhat, but not  
significantly...

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 25 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-02-26 05:50, Brad Roberts wrote:


 The 'build' part of the auto-tester is the easiest part.  The majority
 of the logic is in what to build when and the user interface on top of
 that state.  None of that exists for this use case.  It's not hard
 logic, but it would need to be built.

 This use case can likely also ignore the multi-platform part and stick
 to just building on one which simplifies the job significantly.  And it
 can also likely all be done on one box since it's likely that it can all
 be done in a relatively short period of time.

 All that, in my mind, suggests that while it could be integrated into
 the auto-tester, it gains little in doing so and puts more work on my
 plate and more load on already loaded systems.  I think having a new
 volunteer involved would be more long term beneficial.


How much worked would it be to rewrite the auto tester to not use the 
proprietary systems it currently does? I'm thinking this would make it 
easier for others to help.

-- 
/Jacob Carlborg
Feb 26 2014
prev sibling next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
On 2014-02-26 05:50, Brad Roberts wrote:

 Later,
 Brad


Hi, It's kinda hard to reach you by email, I've sent 3 of them :) Would 
you like to accept ARM board for auto tester? Please contact me on NG 
email if you wish.
Feb 26 2014
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
On 2014-02-26 05:50, Brad Roberts wrote:

 Later,
 Brad


Now I've received your email but it seems I can't reply :)

Instead, I'm receiving mail delivery error:

  The mail system

<braddr puremagic.com>: host mail2.puremagic.com[99.179.5.161] said: 451
4.7.1
     Please try again later (TEMPFAIL) (in reply to RCPT TO command)
Feb 27 2014
parent Brad Roberts <braddr puremagic.com> writes:
Well, it sounds like one of two issues:

1) you're mail client is sending directly to the mx hosts for 
puremagic.com mails (ie, mail1 or mail2) and never retrying to send. 
Neither is a good idea.

or

2) your mail transport agent is never retrying.

I suspect the former more than the latter, though that'd be highly 
unusual for a mail client to do.

Either way, the 'error' message there is fully descriptive.  You need to 
re-try the send later.  This is standard greylisting behavior which both 
mail servers for puremagic.com use.

On 2/27/14, 1:47 AM, Piotr Szturmaj wrote:

 On 2014-02-26 05:50, Brad Roberts wrote:

 Later,
 Brad


 Now I've received your email but it seems I can't reply :)

 Instead, I'm receiving mail delivery error:

   The mail system

 <braddr puremagic.com>: host mail2.puremagic.com[99.179.5.161] said: 451
 4.7.1
      Please try again later (TEMPFAIL) (in reply to RCPT TO command)
Feb 27 2014