What is the correct deployment topology to use for bake? about bake HOT 4 CLOSED

• It is expected that client and server will both point at the same git repo. The server will update that repo at some point, while the clients will only ever read from the repo. It is indeed expected that the client and server will be identical, because they point at the same time.
• Both client and server only update files in the current directory they are started from. The tests will never be run directly in the repo. I expect you to create a bake-managed directory outside your source repo that you always run clients or servers from - the fact that test creates a subdirectory is mostly an artefact of the test, so I can debug into it more directly.
• Everything is run in a direct subdirectory of the working directory.
• Clients are indeed slaves which only do exactly what the server tells them. In general a test is only run on one client, but there are some cases where if you have multiple clients and dependencies where multiple clients may have to run the same test.

So yes, pretty much correct :)

BTW, you should make sure you use bake from the git repo, not from Hackage, since the code is evolving quickly and I've fixed a number of bugs and made a lot of optimisations - and continue to do so.

from bake.

Thanks for the detailed answer. Yes, I am following closely your repo. BTW, I this raises a question about how to contribute back: I use bake as CI for some proprietary software meaning the repository is a private bitbucket repo. What would be the best way to propose patches/PR? I also have a github clone, so I could imagine propagating back the changes relevant to bake proper to public github repo and propose PR from there. Or I could simply send patches...

First thing I wanted to contribute: I usually do -Wall -Werror in my code so that no warning can escape unattended. I did this on bake code and noticed quite a few places with, among other things, unused bindings, so I started "cleaning" that stuff.

from bake.

Patches are best as pull requests, but I can take a diff if that's easier.

I tend not to be a fan of -Wall. Some of the GHC errors, like unused variables, can be downright unhelpful - e.g.

map f [] = []
map f (x:xs) = f x : map f xs

This warns about having the variable f in the first line unused. The "fix" is use _ instead of f, which makes a dull bit of the code that is deliberately unchanging suddenly into something special, and hurts readability. That said, it also catches things like let x = 1 in y, where the binding of x is totally pointless, but I'm not a fan of blindly avoiding all warnings. I also test using CI with -Werror, but don't write it in the cabal file, so I get notified of all warnings but it doesn't break for my users.

from bake.

Good point. But I think the upside wins in the end, even if there are a couple annoying warnings like the one you notice.

from bake.