How do I know the commit id for a 'test' action? about bake HOT 11 CLOSED

The information is available in the prepare step, so I'd just write it to a file in the prepare step, and read the file in the test step. Preparation and tests are guaranteed to run in the same directory for a given patch, so that will work fine. You could imagine a custom Oven modifier that wrote out the information and provided an API to read it later, if you wanted a bit more abstraction.

BTW, I'll likely be pushing a patch to significantly change Bake later today or tomorrow, changing the algorithm by which new patches are started testing. Basically it will now test a patch completely before rejecting it, rather than stopping on the first test. I imagine it won't make too much different to you, but if it does, let me know.

from bake.

Hi Neil,
Thanks a lot for the quick answer. So the question becomes: how do I modify the prepare step? ARe you suggesting I write a ovenStorePatch:: Oven state patch test -> Oven state patch test function that does this? Which simply wrap/overrides ovenPrepare to generate the mentioned file... Ok, that's pretty clear now. Wondering what's the actual type of patch...

Regarding the changes you plan to push: We are currently working on our first go live so I have not been pulling changes from bake for more than a month I think, if not more. And I do not want to break changes now so I won't pull it before couple of weeks. Then I hope I will have some spare time to start working seriously on the CI and delve deeper in bake :-)

from bake.

Yes, I suggest you add ovenStorePatch which calls the previous ovenPrepare and then writes out the file. Note that Oven contains ovenStringyPatch which can convert patches to strings and back again, so just use that and you'll remain polymorhpic in patch. If you are using ovenGit then the type of patch will end up being SHA1.

Very sensible to avoid pulling while you are working on a go live. We're also working on a go live, but I'm using the repo as a synchronization point between the servers all over the globe. I suggest once our go lives are done we sync up and discuss where they differ.

from bake.

I am in the process of writing it :-) Thanks for the tip on using ovenStringyPatch, will make it more portable and generic and easier to write to a file. Honestly, I am having a hard time wrapping my head around that Stringy thing, it happens all around the codebase and somehow mangles things so that I am not sure what I am supposed to work with.

But that discussion gave me lots of insights on bake, actually, so that at least I know understand how to extend it...

from bake.

ovenPrepare is taking a list of patches: can I assume it is in oldest to newest order? My ultimate goal is to be able to deploy some produced container with a tag equals to the SHA1 that produced it, and I was thinking of adding a test step: I currently have Compile that runs the (shake !) build, so I would add Deploy step that would pick up the latest patch from the aforementioned file, then do whatever it needs to do to deploy it. Is this right?

from bake.

95% of Bake is just string processing - see http://www.codemesh.io/codemesh2014/neil-mitchell, slide 33. The basic idea is given a type, you can convert it to a string stringyTo (roughly show), convert it back stringyFrom (roughly read) and display it for the user stringyPretty (some kind of pretty printer). The rule is that To/From should be a bijection (information preserving) but Pretty can throw away some information (e.g. for SHA1 it displays only 6 characters).

ovenPrepare takes patches oldest to newest. If you're interested in getting a single SHA1 then doing git rev-parse HEAD might be another approach. The git recipe applies each patch in order, so the total of them together is the final HEAD in git. Note that you might exclude one patch at some point (it fails a test) so then the last patch in sequence won't always uniquely identify an artefact.

Glad to see the conjunction of Shake and Bake :)

from bake.

You're welcome! That makes a lot of sense actually, given we are pretty much going 100% Haskell anyway. Honestly, we are not focusing currently on build system so it is a bit hard for us all to understand how it works, but it works.

Just to be clear about the semantics of the build proces: after the ovenPrepare runs, the directory contains all the patches applied in order. Then bake run all the tests, and if one of them fails, it fails the build. Or is it running one suite of tests for each commit passed to ovenPrepare ?

from bake.

Sorry for bothering you, but any suggestions on how to test this without deploying? I see there is some Simulation in the source code but don't know how to use it...

from bake.

Simulation is really just for testing - I write properties about how it works and check it really does work in theory, without involving web servers and files etc. Not much use for figuring out how things work.

Yes, ovenPrepare tests a set of patches at once. If a test fails, then it will call ovenPrepare in a different directory with a subset of patches and retry the test there. Basically ovenPrepare sets up your directory and all the other operations for the exact set of patches use that directory.

from bake.

OK, makes sense. Thanks a lot for your help.

from bake.

For the record, here is what I did:

-- | Extract latest patch from state or patches informaiont
-- this introduces a constraint for type of patch and state to be equals, which works well
-- for git but might fail for other systems... Anyway, we don't care for now.
ovenStorePatch :: (state ~ patch) => Oven state patch test  -> Oven state patch test
ovenStorePatch oven@Oven{..}  = oven { ovenPrepare = \ s ps -> do
                                          let latest = extractLatestPatch s ps
                                          writeFile patchFile latest
                                          ovenPrepare s ps
                                     }
  where
    extractLatestPatch s [] = stringyTo ovenStringyPatch s
    extractLatestPatch _ ps = stringyTo ovenStringyPatch $ last ps

I had to ensure equality of state and patch types because there is no patch when the server starts, but there is a state. This works with git of course, but might fail for other kind of state/patch combination...

from bake.