<div dir="ltr">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.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 27 Oct 2017 at 11:45 Jeroen Bransen <<a href="mailto:jeroen@chordify.net">jeroen@chordify.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
Regards,<br>
Jeroen Bransen<br>
<br>
<div class="m_-1626206275535360407moz-cite-prefix">Op 24-10-2017 om 16:39 schreef Adam
Bergmark:<br>
</div>
</div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>HTH,</div>
<div>Adam</div>
<div><br>
</div>
</div></blockquote></div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
<br>
<div class="gmail_quote">
<div dir="ltr">On Tue, 24 Oct 2017 at 11:35 Jeroen Bransen <<a href="mailto:jeroen@chordify.net" target="_blank">jeroen@chordify.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi cafe,<br>
<br>
Does anyone know of a good setup for doing continuous
integration with a<br>
set of Haskell packages, each in its own repository? Just
building<br>
everything upon every commit is not so hard, but to speed up
building<br>
times I'd like to build and test only the minimal set of
packages. In<br>
particular, at a commit for some package A, I would like to
build and<br>
test A and all packages that depend on A.<br>
<br>
The problem is that most CI tools use some notion of 'build
artefact',<br>
which Stack doesn't really seem to give me. Ideally building a
package<br>
results in some object file, which can then be used by the
other<br>
packages. When building failed, packages that depend on it can
still use<br>
the last succesful build. I've tried to look up some Haskell
projects,<br>
but most of them seem to use some ad hoc setup.<br>
<br>
Some pointers are appreciated, as we are using Gitlab a
gitlab-runner<br>
specific option would be great, but I am also open to use
Jenkins or<br>
other tools. And I guess my main struggle now is on the
stack/Haskell side.<br>
<br>
Regards,<br>
Jeroen Bransen<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to
post.</blockquote>
</div>
</blockquote></div></blockquote></div>