How do I `git notes` on git repository after bake has run? about bake HOT 19 CLOSED

ovenUpdateState is run after all tests have passed to update the branch reference. There's no way to retrieve all the test results at that point though, but you can know they all passed. One trick would be to write the test logs to disk as they run then read them at that point. At the moment bake doesn't have a great story for deploying assets generated by a run, but it seems reasonable that it should do in future versions.

from bake.

I can do that in the tests definition, and retrieve the result in ovenUpdateState then. So am I safe to assume that this function is run in the mirrored git directory that bake creates when it starts?

Regarding deployment, I see it as just another test, that's how I currently handle it and this works fine.

from bake.

http://hackage.haskell.org/package/bake-0.2/docs/Development-Bake.html#t:Oven documents what you can assume about directories. However, for the moment, I'd treat the implementation as the spec - certainly it's intended that you can jump around directories to grab what you need in a robust way.

Agreed, deployment should just be another test, likely one that depends on all previous tests, and is somehow tied in with updating (so it doesn't run if other tests fail). I haven't yet figured out what that looks like robustly in my head, but the plan is for our bake instance not to do deployment to start with (we'll leave the existing system to do that) so I'm not thinking about it too hard.

from bake.

Ok, things are starting to click in :-) so I guess bake-server contains the
git repository cloned from GIT_REPO. I will check that in source code and
test it with my GIT notes mechanism.

TestInfo holds dependency graph between tests, right ? So it should be
easy to build a correct deployment test. I assumed that the list of tests
passed to ovenTest induces already an order among tests, but I may be
wrong: given enough clients, server can distribute list of tests over
available clients, only taking care of dependencies in TestInfo, right ?

Le mardi 17 mars 2015, Neil Mitchell [email protected] a écrit :

http://hackage.haskell.org/package/bake-0.2/docs/Development-Bake.html#t:Oven
documents what you can assume about directories. However, for the moment,
I'd treat the implementation as the spec - certainly it's intended that you
can jump around directories to grab what you need in a robust way.

Agreed, deployment should just be another test, likely one that depends on
all previous tests, and is somehow tied in with updating (so it doesn't run
if other tests fail). I haven't yet figured out what that looks like
robustly in my head, but the plan is for our bake instance not to do
deployment to start with (we'll leave the existing system to do that) so
I'm not thinking about it too hard.

—
Reply to this email directly or view it on GitHub
#7 (comment).

Arnaud Bailly

twitter: abailly
skype: arnaud-bailly
linkedin: http://fr.linkedin.com/in/arnaudbailly/

from bake.

In general I always operate one directory below the root, so you can always do .. to get back and to anything else.

Indeed, TestInfo is the dependencies, and it requires the dependencies to have all run and passed. There is no order between the tests, and indeed, I distribute them freely given multiple clients.

from bake.

Got one more question to solve this thing.

Let's say I somehow write output of tests into some file, those files would be in bake-test-xxx directory, where xxx is some hash computed from the current state and list of patches, right? Then within ovenUpdate, which runs into bake-server directory, how can I safely retrieve those outcomes? I can imagine reconstructing the directory names from state and patches, but that somehow fells like depending on implementation details.

Alternatively, I could write the outcomes into some bake-outcome-xxx file at root directory where xxx would be uniquely determined by test run. This probably means factoring test identity, state and patch into this hash.

Thoughts?

from bake.

So I tried the following but nothing appears in my refs/notes/*...

ovenGitNotes :: (state ~ patch) => String -> Oven state patch test -> Oven state patch test
ovenGitNotes repo oven@Oven{..} = oven{ ovenUpdateState = \ up -> do
                                             s <- ovenUpdateState up
                                             pushNotes ovenStringyPatch repo up
                                             return s
                                        }

pushNotes :: Stringy s -> String -> Maybe (s, [s]) -> IO ()
pushNotes _  _    Nothing        = return ()
pushNotes sy repo (Just (s, ps)) = do
  let latest = extractLatestPatch sy s ps
  () <-  cmd "git fetch" [repo] ["refs/notes/*:refs/notes/*"]
  () <-  cmd "git notes append --ref=bake" ["-m", "build successful", latest]
  () <-  cmd "git push" [repo] ["refs/notes/*"]
  return ()

I do not have any trace of this execution either. Not sure how to make bake's output more verbose at least in logs so that I can debug what's going on. For some reason that might be related, the Slack hook I had setup which notified end of build does not work anymore.

Thanks for any help.

from bake.

Actually, something happened! I was observing the result of init which obviously does not invoke ovenUpdateState. Now I got a Failed to update error but without any other message and the server's logs are empty. What can I do to get more tracing?

from bake.

Found it. It's in the server's logs...

from bake.

Works ok now. Would still be interested in your insights on how to get more information from the build context without resorting to parsing directory names. Or maybe that's just the solution currently...

from bake.

I think currently there's no real solution, and the fact that multiple slaves are used to execute tests may mean that just looking up in a directory isn't a workable solution (in general, with only one slave it probably is). I am starting to get to these points in my use of Bake, and I don't yet have a good solution, but I'll think more tomorrow...

For failed to update messages you should be able to go to the main web page, go to the Server section under clients near the bottom, and hit a link to see the stdout. It should also mark your build system as fatally broken and write that at the top of the page. It's possible those enhancements aren't in your version, and I had actually broken them a week ago, but fixed them earlier today.

from bake.

Oh, I also changed the update today so it runs in the same directory as the ovenPrepare, which should mean you can directly get the files out if you are running the client and server in the same directory.

from bake.

Thanks, makes sense but obviously bake's distributed nature is a great strength so it would be silly to rely on colocated client and servers. Actually, I would be happy with the just the short outcomes that are displayed in html by the server on its front page, there may be a way to retrieve them?

from bake.

OK, I suggest the right thing to do is:

• All updates are run in bake-update-.hash.
• In the Update directory there will be a log for each hash, perhaps a function to go from test name to log name.
• Any test will be able to declare itself as producing some artifact, by returning a list of files. These will also be retrievable.

For the moment, I suggest you hack it locally, but if that sounds like a good final plan I can work towards it.

from bake.

Hi Neil,
The last one would imply some other messaging, right? To ask a "producer" to retrieve whatever "artifact" is has produced. This looks reasonable. In the meantime I will find some local workaround.

I will close this issue then and maybe create another for Provide a way to retrieve tests results during update phase. WDYT?

from bake.

The producer already passes the stdout from the client to the server, so its just extending that to send more than one file. Sure, another ticket works for me.

from bake.

(of course, "just" in this case isn't trivial, but it also isn't impossible or a new type of messaging either)

from bake.

Great. If I feel lucky and have some time, I would be more than happy to help.

from bake.

Thanks for the offer of help, at the moment things are going quite nicely - once we've both got our deployments out the door we should think about what hacks need cleaning up.

from bake.