Plugin for all users

Asked by martin dunford

I wrote a plugin that is activated prior to a commit (PRE_COMMIT)
and this works fine for me so long as my BZR_PLUGIN_PATH points to its
location on my PC.

My question is how do activate this for all bazaar users at our company?

The only solution I can think of is very tedious. I would have to edit
/etc/environment and define BZR_PLUGIN_PATH on there for all
our PCs. And then ensure the plugin file is at that location on all
machines.

There has to be an easier way? does anyone know what it is?

Thanks in advance !

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
martin dunford
Solved:
Last query:
Last reply:
Revision history for this message
Martin Pool (mbp) said :
#1

You shouldn't need to set BZR_PLUGIN_PATH as long as you install your file into somewhere on the default plugin path. For example on Ubuntu maverick you can put it into /usr/lib/python2.6/dist-packages/bzrlib/plugins, or you could put it into ~/.bazaar/plugins.

Revision history for this message
martin dunford (mdunford) said :
#2

Thanks but I don't see how this addresses the key question here which is that the plugin must be
activated prior to a commit on *any* machine for *any* user. Do I have to laboriously
add it to the default plugin path on every last PC ( and worse ensure it gets added
to new PCs people fire up and start to use? ). They key here is no one is supposed
to be able to commit t o the bzr repiository without my plugin running first and asking
them for info (in this case a bug number they are supposed to be fixing)

Revision history for this message
Marius Kruger (amanica) said :
#3

maybe use a pre-tip-change plugin on the server and only allow smart-server commits e.g. through bzr+https://

Revision history for this message
martin dunford (mdunford) said :
#4

Thanks but I am still very confused!

Can I copy my pre-commit plugin to the bzr central repository server
( /usr/lib/python... site-packages/bzrlib/plugins directory )? so that whenever
a user does bzr commit (after checkout from repository)
my plugin is triggered?

Why do you mention pre-tip-change and what is it?

Revision history for this message
Marius Kruger (amanica) said :
#5

yes, I think if you put your plugin on the server you can prevent undesirable commits if
the clients use a smart-server protocol eg. bzr+https://

I think the pre-change-branch-tip would be better to use since it will also be triggered when changes are pushed to the server. So this will prevent any undesirable revisions to make it onto the server.
http://doc.bazaar.canonical.com/development/en/user-reference/hooks-help.html#pre-change-branch-tip

Revision history for this message
martin dunford (mdunford) said :
#6

I have BZR_PLUGIN_PATH = ~/bzr_plugins/p1.py on PC1.

p1.py registers a pre_change_branch_tip plugin.

I start "bzr serve...." on PC1. No problem.

I do "bzr checkout bzr://PC1/home/branches/...LATEST" on PC2.

I make some changes in LATEST and do a

"bzr commit -m "blah" ...." <files>

Nothing, no plugin activation.

I cannot figure this out. It seems so basic. bzr server sees a checkin/commit/branch-tip-change, triggers
a plugin. But it doesn't happen.

Revision history for this message
Martin Pool (mbp) said :
#7

Normally BZR_PLUGIN_PATH is a list of directories containing plugins, not the plugin file names themselves. What happens if you run 'bzr plugins' on PC1? If 'bzr serve' is being run as a different user or from a startup script perhaps it's not seeing that environment variable?

Revision history for this message
martin dunford (mdunford) said :
#8

Thanks

BZR_PLUGINS_PATH was actually set to the directory (my typo)

It all seems to work now. I added a "raise Exception" to my plugin code
and sure enough when I tried to do a commit from PC2 I got an error
back from the server on PC1. I then replaced plugin code with a one liner
 to echo something to a file and sure enough the file got created on PC1 on the next commit.

So my plugin code was doing something strange it appears.

I now need to figure out how the server side plugin can demand a
bug number from the commit client. I am guessing this will involve
raising some manner of Exception.

Thanks for all the help

Revision history for this message
Martin Pool (mbp) said :
#9

On 15 September 2010 00:41, martin dunford
<email address hidden> wrote:
> I now need to figure out how the server side plugin can demand a
> bug number from the commit client. I am guessing this will involve
> raising some manner of Exception.

Yes, probably examine the proposed revision and raise an exception.
Feel free to post again. In fact it would be nice if you can give
some example code of how you do this, because it's probably something
more people would like to do.

--
Martin

Revision history for this message
martin dunford (mdunford) said :
#10

I've tried raising all manner of exception (subclassed from BzrError) in the
server side plugin but the client invariably reports something like
(See below for plugin code)

bzr: ERROR: Server sent an unexpected error: ('error', 'Hook \'Test Hook \' during pre_change_branch_tip failed:\n File "/usr/lib/python2.5/site-packages/bzrlib/branch.py", line 979, in _run_pre_change_branch_tip_hooks\n hook(params)\n File "/home/mdunford/.bazaar/plugins/simplePlugin.py", line 15, in hook1\n raise PointlessCommit\nNo changes to commit')

I can at least use this mechanism to prevent commits to a production branch but would
prefer to be able to

- send a message back to the client
- somehow get the correct information (a bug number in this case) from the client

Any suggestions welcome.

(in this case my plugin did a "raise PointlessCommit")

import os,sys
from commands import *

from bzrlib.branch import Branch
from bzrlib.errors import BzrError,UserAbort,MalformedBugIdentifier,PointlessCommit

def hook1(changeBranchTipParams):

    try:
        message = 'Simple server side (%s) plugin (located in ~/.bazaar/plugins) triggered on %s' % (getoutput('uname -n'),getoutput('date'))
        os.system ('echo "%s" > ~/bzrMessage1' % (message) )
        #raise MalformedBugIdentifier (123,"UNknown Bug ID")
        raise PointlessCommit
    except Exception:
        raise # raises the exeception that got us here again

Branch.hooks.install_named_hook('pre_change_branch_tip', hook1,
                                'Test Hook ')

Revision history for this message
martin dunford (mdunford) said :
#11

Also does anyone know how to extract the fixes string (using the API) from
the changeBranchTipParams passed into my plugin when I do a:

bzr commit --fixes citrius:1244

 I can probably figure this out but just in case anyone knows it straight off !
Thanks

Revision history for this message
martin dunford (mdunford) said :
#12

A colleague figured it out. The Exception that is needed is

   raise TipChangeRejected("Where is the bug number for your fix?:")

which then shows up on the client as:

     bzr: ERROR: Tip change rejected: Where is the bug number for your fix?:

which neatly solves the problem.

Revision history for this message
martin dunford (mdunford) said :
#13

Following server side plugin will insist on bugfix/bugid number being supplied
for any commits. Right now it is hard wired to rejecting the commit and
raising a TipChangeRejected(rejectMsg). The remote client will see the
rejectMsg and can act accordingly ....

Thanks for all the help on this!
___________________________________

import os,sys
from commands import *

from bzrlib.branch import Branch
from bzrlib.errors import BzrError,UserAbort,MalformedBugIdentifier,PointlessCommit,TipChangeRejected

from bzrlib.bugtracker import tracker_registry

def hook1(changeBranchTipParams):

    try:
        myBranch = changeBranchTipParams.branch
        new_revid = changeBranchTipParams.new_revid
        revision = myBranch.repository.get_revision(new_revid)
        commit_msg = revision.message

        # For the case of e.g Launchpad being used as Bug Tracker and client commiting using
        # "bzr commit -m "Fix for null pointer in bk_setup" --fixes lp:1235 "
        tracker = tracker_registry.get_tracker ("lp",myBranch)

        # Extract 1235 from 'https://launchpad.net/bugs/1235 fixed'
        try:
            bugs = revision.properties['bugs']
            bugId = bugs.split()[0].split(tracker.base_url)[-1]
        except Exception:
            bugId = None

        if bugId:
            rejectMsg = '''

            You supplied Bug ID: %s
            This is an invalid Bug ID.
            Please try again!
        ''' % bugId
        else:
            rejectMsg = '''

            You must supply a bugfix number using " --fixes lp:1234" field in commit
            '''

        raise TipChangeRejected(rejectMsg)

    except Exception:
        raise # raises the exeception that got us here again
        pass
i