In order to automate deployment a common way with Git is to make use of its "post-receive" hook.

What is the fossil way of doing this?

For an easy example, I have HTML/CSS code in my fossil repo which I would like to be automatically deployed to my web servers chroot.

Thank you very much.

AI

I posted a script that you can customize to achieve this end.

But when and how do you call this script?

In git the post-receive hook (script) is executed everytime something is pushed to the repo.

I do not see yet how this is achieved with fossil.

Call it from a cron job once a minute. It may miss commits in rapid sequences, but for some applications (e.g., CI/CD) it suffices.

so in broad terms the fossil "automation algorithm" is:

frequently (e.g. via cronjob once a minute) look for changes (e.g. using fossil rss) and do the automation work (e.g. deploy or compile code).

So there is no such feature as "call script X upon receiving push" in fossil (compare git hooks), correct?

So there is no such feature as "call script X upon receiving push" in fossil (compare git hooks), correct?

There is not. We have talked about it, but nobody has felt the need to have such a thing that they have devoted the time to make it happen.

Part of the problem here is that a "push" in Fossil is not necessarily transmitting a complete update. As far as the Fossil push/pull/sync mechanism is concerned, a repository consists of a bag of "artifacts". The push/pull/sync mechanism does not know which artifacts are file changes, which are commit records, which are tickets, wiki pages, forum posts, etc. It sees everything as just a bunch of binary artifacts. A "push" means sharing artifacts with a remote repository. Do the artifacts shared contain a complete update to a branch? The push/pull/sync mechanism doesn't really know that, and so it doesn't really know if a new check-in has been received or not. Maybe the new artifacts are wiki page edits. Or new tags. Or a change to a ticket. And even if the push/pull/sync mechanism were able to discern that a new check-in had been received, it wouldn't have an easy way to determine which branch that check-in was applied to. Hence, the push/pull/sync mechanism doesn't have a clear way of knowing when to call the "post-receive" script.

All of these obstacles can be overcome. But it isn't a one-line change. And, so far, nobody has had a sufficiently compelling need for the capability that they have taken the time to figure it out.

the push/pull/sync mechanism doesn't have a clear way of knowing when to call the "post-receive" script.

If the wish is simply that the script is called within milliseconds of the bits hitting the disk instead of up to a minute later, then you could monitor the repo DB file for changes, then call fossil rss to get the masticated form of the data, which sorts out the issues you bring up.

The real sticking point about hooks, to my mind, is quite another thing: give people a method to register hook scripts directly, and then they start wanting enforcing hooks, which becomes a whole new hairball in a DVCS:

1. Your users are on different platforms. How do you write your client-side hook scripts portably enough that they run everywhere?

2. When (!) you write a bug in a client-side hook script, have you just locked yourself out of updating it because the hooks are preventing a pull of new info?

3. What happens if you're offline at the time of a commit, and you're using server-side pre-commit accept hooks to get around the above two problems? Does the commit go into the local blockchain anyway, but then fail to sync forever more because the server script never allows the push? How does the client recover?

then you could monitor the repo DB file for changes,

That was the answer I was looking for. Much better than periodically running a cron job. In OpenBSD there is also entr for watching file changes.

The real sticking point about hooks, to my mind, is quite another thing: give people a method to register hook scripts directly, and then they start wanting enforcing hooks, which becomes a whole new hairball in a DVCS:

As far as I know Git's post-receive hook is a server side hook.

Admittedly I never really used any other Git hooks, client or server side.

Nonetheless the concerns you share make sense.

Thank you for your comment.

So there is no such feature as "call script X upon receiving push" in fossil (compare git hooks), correct?

Sort of.

There is the (poorly documented) transfer TH1 script mechanism. The setup pages are /xfersetup_com, /xfersetup_commit, /xfersetup_push and /xfersetup_ticket

I think this mechanism has to be enabled at build time and defaults to disabled.

These scripts must be coded in Fossil's TH1, however, the TH1 scripts can call TCL scripts if TCL support is enabled at build time.

How useful this is, I don't know. I've never experimented with it.

Besides Warren's script that uses /timeline.rss, there is also the fossil rss command. See https://fossil-scm.org/forum/forumpost/fdba60d11d

Thank you folks, this is awesome!!!

I tried this with my post here: https://fossil-scm.org/forum/forumpost/9c87a3c8d9a93528b2cdce7374ffaea4ccb96a73e0edc951766b1d4543a25364 but I got nowhere. Did you recompile Fossil at all to make this work?

http -asynchronous -- https://discordapp.com/api/webhooks/585209245658644494/((REDACTED)) {{content: 'hello there'}}

and also just

http -asynchronous https://discordapp.com/api/webhooks/585209245658644494/((REDACTED)) {{content: 'hello there'}}

The documentation/output or lack thereof makes it difficult to debug or understand what I can really discern as a problem.

Did you recompile Fossil at all to make this work?

$ ./configure --help
Usage: configure [options] [settings]

...

  --with-th1-hooks                    Enable TH1 hooks for commands and web pages