[Haskell-cafe] Haskell CI with many repositories/packages

Adam Bergmark adam at bergmark.nl
Fri Oct 27 12:42:25 UTC 2017


But you could check whether sharing the .stack-work would even be a
noticeable improvement. Unless your projects change often and take a lot of
time to build (excluding dependencies) then I don't think it would.


On Fri, 27 Oct 2017 at 11:45 Jeroen Bransen <jeroen at chordify.net> wrote:

> That is similar to what I am doing now, but I don't think this solves my
> problem. When I have a package A depending on B, I make a mistake in B such
> that it doesn't compile, then commit something correct to A, the build for
> A will also fail because of this error in B. I would like to let A be based
> on the last succesful build of B, but with shared `.stack-work` I don't
> think that's going to work.
>
> Regards,
> Jeroen Bransen
>
> Op 24-10-2017 om 16:39 schreef Adam Bergmark:
>
> I haven't felt the need to share build artifacts like this. Instead, e.g.,
> if you cache your `.stack-work` and your master project does a git clone of
> sub projects and you put those paths in your stack.yaml then `stack build`
> should only rebuild the changes. You may be able to share parts of
> `.stack-work` as well but I haven't looked into that.
>
> HTH,
> Adam
>
>
> On Tue, 24 Oct 2017 at 11:35 Jeroen Bransen <jeroen at chordify.net> wrote:
>
>> Hi cafe,
>>
>> Does anyone know of a good setup for doing continuous integration with a
>> set of Haskell packages, each in its own repository? Just building
>> everything upon every commit is not so hard, but to speed up building
>> times I'd like to build and test only the minimal set of packages. In
>> particular, at a commit for some package A, I would like to build and
>> test A and all packages that depend on A.
>>
>> The problem is that most CI tools use some notion of 'build artefact',
>> which Stack doesn't really seem to give me. Ideally building a package
>> results in some object file, which can then be used by the other
>> packages. When building failed, packages that depend on it can still use
>> the last succesful build. I've tried to look up some Haskell projects,
>> but most of them seem to use some ad hoc setup.
>>
>> Some pointers are appreciated, as we are using Gitlab a gitlab-runner
>> specific option would be great, but I am also open to use Jenkins or
>> other tools. And I guess my main struggle now is on the stack/Haskell
>> side.
>>
>> Regards,
>> Jeroen Bransen
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20171027/eb92ddea/attachment.html>


More information about the Haskell-Cafe mailing list