I’m working on setting up my Fossil server so that certain tasks are kicked off
after someone pushes changes to it. Push transfer scripts seem like the right
tool for this. Because of the nature of the work that needs to happen after a
push, I have my TH1 script ‘tclInvoke exec’ an external script that takes the
hash of a checkin contained in the push. Something like:
tclInvoke exec /bin/sh -c “foo.sh $hash" >> /tmp/commit_hook.log
Where $uuid is a TH1 variable containing the hash of a checkin.
My script needs to collect some information about the checkin so it does the
following to get the manifest:
echo "select content(‘${hash}');" | fossil sql -R foo.fossil
When testing the script in isolation, this works great. However, when run from
a push transfer script, the artifact identified by the hash isn’t found.
Looking through the source to Fossil it looks like the push transfer script
gets executed before the database transaction for the push has been committed.
So, it makes sense that my script wouldn’t find the artifact in question.
The Fossil UI describes the Push transfer script as: 'Specific TH1 code to run
after "push" transfer requests.’ I was reading the “after” to mean after the
push had been committed to the Fossil database, but this isn’t how it is
implemented.
This leaves me with the following questions:
- Is it intentional that the push transfer script is executed before the push
has been committed or is this a bug? (I can see the utility of a script
executes before a push is committed in order to give it the chance to reject
the push, but I’m not sure if this is the intent here).
- If it is intentional, would a patch implementing a “post-push” transfer
script that only gets executed after the push has been committed be acceptable?
- Are there other suggestions that I haven’t though of?
Thanks,
--
Ryan
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
