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 "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
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 "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
prev sibling next sibling parent 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
prev sibling next sibling 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 next sibling 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 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 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 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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling 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 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