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