June 23, 2015
On 23 June 2015 at 18:40, Marko Anastasov via D.gnu <d.gnu@puremagic.com> wrote:

> On Tuesday, 23 June 2015 at 14:57:55 UTC, Iain Buclaw wrote:
>
>> On 23 June 2015 at 12:31, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>>
>>> On 23 June 2015 at 10:15, Marko Anastasov via D.gnu <d.gnu@puremagic.com> wrote:
>>>
>>>> On Monday, 22 June 2015 at 08:56:54 UTC, Iain Buclaw wrote:
>>>>
>>>>>
>>>>> So, I'd be willing to hear of alternatives:
>>>>>
>>>>> https://semaphoreci.com  - However CPU's given are 2, and time to build and run tests is limited to 60 minutes.
>>>>>
>>>>
>>>>
>>>> Hi Iain,
>>>>
>>>> Semaphore cofounder here. The first point is correct, however the 60 minute limit applies to single build commands, not the entire build. If you can compose your build of n commands, each < 60 minutes, it'll be fine.
>>>>
>>>> I invite you to give Semaphore a try. We'd love your feedback. And I'm here for any questions you may have. :)
>>>>
>>>>
>>> Hi Marko,
>>>
>>> Thanks for the update.  Yes, each command step is easily done in 20 minutes.  I just have a few questions which I couldn't find answers for in the documentation.
>>>
>>>
>>
>> OK, I went ahead and tried it out anyway, and was surprised to find that
>> everything went smoothly on the first (proper) build!
>>  So I send out my kudos to Marko on the ease of use (once I got around
>> how the interface works).
>>
>>
> I’m very happy to hear that — thanks!
>
> I’ll reply to your earlier questions below.
>
>  1. What kind of storage and memory quotas are in-place on the build
>> environment?
>>
>
> 4GB of storage is fine. Currently we have a ~4GB soft limit on RAM, going over that would notify us and we’d discuss it with you directly.
>
>
OK, good to know.  Let's hope that the current parallel settings don't trigger the the soft limit too often then.


 3. How are caches in Semaphore stored?  Is there a size limit for files in
>> cache?  Do they expire?
>>
>
> You can consider them to be on the same local network where the machine running your build is. There’s a special `.semaphore-cache` directory which you can use to store arbitrary files:
>
> https://semaphoreci.com/docs/caching-between-builds.html
>
> Cache hit is not yet 99% but it’s our goal to reach it.
>
>
So it is possible to manage the `.semaphore-cache` directory in a scriptable way then?  I'm thinking in terms of checking whether a tarball exists either downloading or extracting based on the outcome.

I see that is an `Expire Dependency Cache` button for the build, I assume this cleans up the `.semaphore-cache` directory for us.

Iain


June 23, 2015
On Tuesday, 23 June 2015 at 17:48:23 UTC, Iain Buclaw wrote:
>
> So it is possible to manage the `.semaphore-cache` directory in a scriptable way then?  I'm thinking in terms of checking whether a tarball exists either downloading or extracting based on the outcome.

Yes, the directory is always present and you can write a script based on the presence or absence of its content. Note that Semaphore build commands can be Bash commands too. Some people tend to encapsulate things in a .sh file as things get more complex.

>
> I see that is an `Expire Dependency Cache` button for the build, I assume this cleans up the `.semaphore-cache` directory for us.

Yes.


June 23, 2015
On 23 June 2015 at 20:05, Marko Anastasov via D.gnu <d.gnu@puremagic.com> wrote:

> On Tuesday, 23 June 2015 at 17:48:23 UTC, Iain Buclaw wrote:
>
>>
>> So it is possible to manage the `.semaphore-cache` directory in a scriptable way then?  I'm thinking in terms of checking whether a tarball exists either downloading or extracting based on the outcome.
>>
>
> Yes, the directory is always present and you can write a script based on the presence or absence of its content. Note that Semaphore build commands can be Bash commands too. Some people tend to encapsulate things in a .sh file as things get more complex.
>
>
>> I see that is an `Expire Dependency Cache` button for the build, I assume this cleans up the `.semaphore-cache` directory for us.
>>
>
> Yes.
>
>
>
OK, Thanks.  I've added in some logic using the exposed `BRANCH_NAME` environment variable, and now saving tarballs to cache.  Just triggered a build for gcc-5, gcc-4.9, and gcc-4.8 on my own repository.  I'll re-trigger one last build for master to verify that the tarballs are kept locally between builds, then I'll promise I'll stop "hammering" your build servers. :-)

@Johannes, I've created a GDC team on semaphoreci, will add you to it along with the build configuration I've set-up so far.  I imagine this will be rolled out tomorrow.  Let's see how this goes...

Iain.


June 24, 2015
Am Tue, 23 Jun 2015 20:46:41 +0200
schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:

> @Johannes, I've created a GDC team on semaphoreci, will add you to it along with the build configuration I've set-up so far.  I imagine this will be rolled out tomorrow.  Let's see how this goes...

Sounds great! My semaphoreci account is jpf91.
June 24, 2015
On 24 June 2015 at 08:32, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> Am Tue, 23 Jun 2015 20:46:41 +0200
> schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:
>
>> @Johannes, I've created a GDC team on semaphoreci, will add you to it along with the build configuration I've set-up so far.  I imagine this will be rolled out tomorrow.  Let's see how this goes...
>
> Sounds great! My semaphoreci account is jpf91.

Added you do Team GDC (kept the organization structure and names identical to our conventions on github).

And we are building!

https://semaphoreci.com/d-programming-gdc/gdc

Regards
Iain
1 2
Next ›   Last »