Hi Ross:
In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>,
Ross Berteig writes:
>On 5/27/2016 3:58 PM, John P. Rouillard wrote:
>> Hi Richard:
>>
>> Richard Hipp writes:
>>> Just to be clear, I consider anything involving shunning to be
>>> out-of-the-ordinary.
>>
>> Perfectly reasonable.
>>
>> On that note, does anybody have code for tcl hooks that can be used to
>> reject artifacts that have text that matches a particular pattern....
>
>IMHO, that is capability is outside the core mission of
>fossil. One of the great selling points of fossil to new users
>is the low ceremony of fossil. One executable. A repo is a
>single file, that can even safely reside in the same folder as
>your checkout. And very little policy is enforced by fossil
>directly.
I agree that the low ceremony feature of fossil is excellent. I
am *not* suggesting that the th1/tcl code to enforce policy be
supplied by default. However I was expecting that the fossil
hooks would operate similar to hooks/triggers (and similar
mechanisms) in svn, cvs, git, perforce ....
>That said, there is a hook mechanism that can be used to check
>preconditions before executing a command. It might require some
>cleverness to use it for this purpose, however.
Yup, cleverness is what I am looking for. I was expecting that I
could do the following from a hook:
1) Get the current manifest for the checkin (passed to the hook
script)
2) Using the manifest, find a list of new artifacts added
in this commit transaction (e.g from th1:
set manifest [fossil artifact <manifest SHA1>]
)
3) Analyze the manifest for filenames and artifact id's and be
able to "fossil artifact" these new artifacts to analyze the
contents
4) verify the checkin comment contents (by looking for the C
card in the manifest): E.G. does the checkin comment have a
reference to an open ticket.
5) Identify the user who made the commit (U card in manifest IIRC)
6) Abort the commit from the hook causing the artifacts be
removed and the user to be notified with a message from the
hook script.
However from what you say below it looks like the hook is at the
wrong level for me to do any of this.
>Hooks exist if fossil is compiled with the option, are written
>in TH1, can configured to make Tcl available to TH1, and are not
>extensively documented.
So I have noted 8-). Even some light code groveling failed to
enlighten me.
>One of the hooks is "command_hook" which is invoked for every
>fossil command. That name can raise an error (or call break or
>continue) to prevent the fossil command from executing.
>
>Since the hook is called early, it knows the command name, its
>arguments, its flags, and not a lot lse.
Well if the hook was executed, I could use it to reject a
--no-th-hooks, but ironically it would never see it 8-).
>Hence the need for cleverness since you would want to learn what
>files are going to be committed.
>
>This hook has to run at the client, and before the commit is
>performed. So that won't prevent a user from bypassing it, or a
>misconfigured repository from failing to call it, or if depending
>on Tcl, I'm sure there are more failure modes since Tcl is
>(usually, depending on configuration of fossil) loaded from the
>system at run time.
Agreed. I would expect that only the central repo would be
guaranteed to run the hook, but that doesn't stop repo clones
from also having the hooks so that they don't commit things that
would be rejected upstream.
Obviously I would also need access in the hook to see if the
branch is private or not so I could bypass the hook on a private
branch (that won't be pushed upstream).
However I would expect the server would run the hook on an
incoming commit.
Hmm, now that I think about it, are all the hooks defined in the
"transfer"(xfersetup) admin page, so they are only run on the
client?
>> .... If you really wanted to commit a file that matched that
>> pattern, you added a string like: BYPASSPASSWORD to the commit
>> message and the check would be bypassed.
>
>The fossil -no-th-hooks option will skip all hooks for that
>command. Depending on what else you do in a hook, that might be
>more than you wanted.
Yup. The embedded codeword allowed fine grain tuning of the
checks and also recorded whet the developer requested so s/he was
accountable for the bypass. If any client can disable hooks on
the remote central repo without any logging/accountability this
is all moot.
>>Is there some similar way to inspect the transferred artifacts
>>and file contents and roll back the commit?
>
>Nope. And there can't be. Nothing is transferred until well
>after the whole collection of artifacts that make up the commit
>have been created and safely stowed in the local
>repository. There is no "roll back" from that.
Err, that's unfortunate. I was expecting that the order of operations
for a commit on the server (or a local repo) would be:
open connection to client (or in the case of local file access,
just open the sqlite file)
start transaction in database
(possibly invoke hook to validate access for user (if remote
repo), but I expect the usual permissions would be sufficient
since at this point I have no info about what files are being
changed by the user.)
pull artifacts into transaction which is not visible to other
users yet.
invoke th1/Tcl hook "pending commit" allowing the hook access
to the current db transaction passing the manifest (SHA1) for
the transaction
if "pending commit" hook fails, roll back transaction and
reject the commit. Notify client with rejection message; exit
(if local repo, push to upstream repo (if enabled))
if "pending commit" hook succeeds (and push succeeds)
commit transaction
invoke hook "committed" with manifest
let hook go do its thing:
* tickle Jenkins on a private network to update and perform
a new build,
* send email ....
* deliver a a cup of coffee to the PM....
You have raised an interesting question, what to do with
artifacts in a local repo that can never be transferred to the
upstream repo because of the hook. These could be moved to a
private branch to stop them from syncing, but it does fly in the
face of the one bit of ceremony fossil does require:
>[..] the big one: fossil preserves everything, and that history
>is immutable.
Overall it sounds that wrapping tools are required to support
process and validation with fossil rather than supporting the
process within fossil.
Thanks for an interesting discussion.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
