stalling commits until approval

[Tucker <ju...@gmail.com>]

Does anyone know of a, relatively, simple way to block commits,
without approval?  For the sake of context, here's the actual need:

The company I work for has decided (correctly) that we need to keep
out system configuration scripts (puppet) in Subversion.  Migrating
all of this is a rather trivial task but adding sanity to changes is
one of my top priorities.  Since puppet has the power to do "Bad
Things," when you mess up a config, we'd like to require change
approval.  The suggestion I've heard, thus far, is to have release and
development branches and integrate from the dev branch, once a change
has been approved.  While doable, this isn't the most scalable
solution.  What I'd like to see is something more like this:

1) Admin makes a change and attempts to commits
2) Pre commit sends out a request for peer review
3) Second admin either approves the change or adds feedback
4) Once approved, the original admin can now commit to release branch

Using dev and release branches, something like this seems feasible:

1) Admin makes a change and commits to dev branch
2) Post commit hook sends email, requesting peer review
3) Second admin either approves the change or adds feedback
4) Once approved, the change is picked up by a cron script and
integrated into release branch

Now, where my complete lack of SVN skills show is that I don't know if
this is possible.  Are there additional tags (META?) that can be added
to commits, that can make one of these scenarios possible?  Are there
existing hook recipes, that someone knows of, that could help me along
the way?  Any insight is appreciated.


-- 

--tucker

Re: stalling commits until approval

[Konstantin Kolinko <kn...@gmail.com>]

2010/1/26 Tucker <ju...@gmail.com>:
> Does anyone know of a, relatively, simple way to block commits,
> without approval?  For the sake of context, here's the actual need:
>
> The company I work for has decided (correctly) that we need to keep
> out system configuration scripts (puppet) in Subversion.  Migrating
> all of this is a rather trivial task but adding sanity to changes is
> one of my top priorities.  Since puppet has the power to do "Bad
> Things," when you mess up a config, we'd like to require change
> approval.

Branching and merging aside, you can control to what revision your
production configuration updates to, e.g. by using svn:externals that
point to a specific revision

http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html

Best regards,
Konstantin Kolinko

Re: stalling commits until approval

[Andy Levy <an...@gmail.com>]

On Tue, Jan 26, 2010 at 15:56, Tucker <ju...@gmail.com> wrote:
> Does anyone know of a, relatively, simple way to block commits,
> without approval?  For the sake of context, here's the actual need:
>
> The company I work for has decided (correctly) that we need to keep
> out system configuration scripts (puppet) in Subversion.  Migrating
> all of this is a rather trivial task but adding sanity to changes is
> one of my top priorities.  Since puppet has the power to do "Bad
> Things," when you mess up a config, we'd like to require change
> approval.  The suggestion I've heard, thus far, is to have release and
> development branches and integrate from the dev branch, once a change
> has been approved.  While doable, this isn't the most scalable
> solution.  What I'd like to see is something more like this:
>
> 1) Admin makes a change and attempts to commits
> 2) Pre commit sends out a request for peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the original admin can now commit to release branch
>
> Using dev and release branches, something like this seems feasible:
>
> 1) Admin makes a change and commits to dev branch
> 2) Post commit hook sends email, requesting peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the change is picked up by a cron script and
> integrated into release branch
>
> Now, where my complete lack of SVN skills show is that I don't know if
> this is possible.  Are there additional tags (META?) that can be added
> to commits, that can make one of these scenarios possible?  Are there
> existing hook recipes, that someone knows of, that could help me along
> the way?  Any insight is appreciated.

Rather than doing it automatically (which may not be possible - the
merge might detect conflicts), why not place the responsibility of
reintegrating (step 4) onto the shoulders of the admin who
reviews/approves (step 3)?

RE: stalling commits until approval

[Bob Archer <Bo...@amsi.com>]

> > I thought I had made a suggestion on how you could create an approval
> process... perhaps you didn't see the email.
> 
> I must have missed it.  I did try a search through my archive, prior
> to sending out this e-mail.  Even looked for anything I sent to the
> old list that had replies.

Basically, my suggestion was to have a pre-commit hook that rejects any of these approval required files unless an approval code was submitted in the commit message. If there is not a valid approval code the script would generate a code and store it in a file on the local server. It would email that code with the commit attached to the approval manager/person. The approval person would look at it... and if it looked ok they could forward the approval code back to the dev that made the change. The dev would repeat the commit including the approval code in the commit message. This time, the pre-commit hook would see the approval message, verify it against the stored code it generated, delete the cached approval code and allow the commit. 

So, the flow would be something like... (psuedo code)

IF FileThatRequiresApprovalIsInChangeSet
  IF ApprovalCodeIsInCommitMessage   
    IF CheckForMatchingCachedApprovalCodeForThatFile
      DeleteApprovalCodeCacheFile
      return true
    ELSE
      put "Invalid approval code" to STDERR
      return false (reject commit)
    END
  ELSE 
    Generate Approval Code
    Create Approval Code Cache File
    Email approver with file attached
    put "Commit requires approval" to STDERR
    return false (reject commit)
  END
ELSE
  return true
END

Hope that helps.

BOb

Re: stalling commits until approval

[Tucker <ju...@gmail.com>]

On Tue, Jan 26, 2010 at 1:10 PM, Bob Archer <Bo...@amsi.com> wrote:
>> Does anyone know of a, relatively, simple way to block commits,
>> without approval?  For the sake of context, here's the actual need:
>>
>> The company I work for has decided (correctly) that we need to keep
>> out system configuration scripts (puppet) in Subversion.  Migrating
>> all of this is a rather trivial task but adding sanity to changes is
>> one of my top priorities.  Since puppet has the power to do "Bad
>> Things," when you mess up a config, we'd like to require change
>> approval.  The suggestion I've heard, thus far, is to have release and
>> development branches and integrate from the dev branch, once a change
>> has been approved.  While doable, this isn't the most scalable
>> solution.  What I'd like to see is something more like this:
>>
>> 1) Admin makes a change and attempts to commits
>> 2) Pre commit sends out a request for peer review
>> 3) Second admin either approves the change or adds feedback
>> 4) Once approved, the original admin can now commit to release branch
>>
>> Using dev and release branches, something like this seems feasible:
>>
>> 1) Admin makes a change and commits to dev branch
>> 2) Post commit hook sends email, requesting peer review
>> 3) Second admin either approves the change or adds feedback
>> 4) Once approved, the change is picked up by a cron script and
>> integrated into release branch
>>
>> Now, where my complete lack of SVN skills show is that I don't know if
>> this is possible.  Are there additional tags (META?) that can be added
>> to commits, that can make one of these scenarios possible?  Are there
>> existing hook recipes, that someone knows of, that could help me along
>> the way?  Any insight is appreciated.
>
> I thought I had made a suggestion on how you could create an approval process... perhaps you didn't see the email.

I must have missed it.  I did try a search through my archive, prior
to sending out this e-mail.  Even looked for anything I sent to the
old list that had replies.

>
> I think a lot depends on if you are looking for a security boundary here or just a warning type system.

It's more about process than security.  I don't plan on spending too
much effort on figuring out ways to prevent every work around.  The
focus is more about providing people with a mechanism for doing the
right thing and hoping they don't try to get around it.

>
> Your first set of steps is doable but you would have to implement much more of it. Since you don't really want a pre-commit hook to create such a long wait state.
>
> Your second set up steps is probably more workable. Having a checkin of a file with a certain property in a "approval" branch trigger and email or notification of some type to an admin/aprovver... but I would just make step3/step4 be manual so once approved the admin commits the file to the release branch.

As pointed out in the reply that just came in, there's an issue with
version conflicts.  I actually don't want that to be the
responsibility of the approver.  The approver should be responsible
for the changes to the files and, if a conflict arises, the original
submitter should have to deal with that.

>
> As far as metadata... yes, you can create a version property which would trigger your commit script to disallow a check in of certain files. OF course, those properties would be modifyable for the most part which might be ok if you don't need this to be a security boundary.

Again, that's OK for now.  I'm looking into what I can do with
properties and auto integration scripts.  Thanks for the help.

>
> BOb
>
>

Comments inline.


-- 

--tucker

RE: stalling commits until approval

[Bob Archer <Bo...@amsi.com>]

> Does anyone know of a, relatively, simple way to block commits,
> without approval?  For the sake of context, here's the actual need:
> 
> The company I work for has decided (correctly) that we need to keep
> out system configuration scripts (puppet) in Subversion.  Migrating
> all of this is a rather trivial task but adding sanity to changes is
> one of my top priorities.  Since puppet has the power to do "Bad
> Things," when you mess up a config, we'd like to require change
> approval.  The suggestion I've heard, thus far, is to have release and
> development branches and integrate from the dev branch, once a change
> has been approved.  While doable, this isn't the most scalable
> solution.  What I'd like to see is something more like this:
> 
> 1) Admin makes a change and attempts to commits
> 2) Pre commit sends out a request for peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the original admin can now commit to release branch
> 
> Using dev and release branches, something like this seems feasible:
> 
> 1) Admin makes a change and commits to dev branch
> 2) Post commit hook sends email, requesting peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the change is picked up by a cron script and
> integrated into release branch
> 
> Now, where my complete lack of SVN skills show is that I don't know if
> this is possible.  Are there additional tags (META?) that can be added
> to commits, that can make one of these scenarios possible?  Are there
> existing hook recipes, that someone knows of, that could help me along
> the way?  Any insight is appreciated.

I thought I had made a suggestion on how you could create an approval process... perhaps you didn't see the email.

I think a lot depends on if you are looking for a security boundary here or just a warning type system. 

Your first set of steps is doable but you would have to implement much more of it. Since you don't really want a pre-commit hook to create such a long wait state. 

Your second set up steps is probably more workable. Having a checkin of a file with a certain property in a "approval" branch trigger and email or notification of some type to an admin/aprovver... but I would just make step3/step4 be manual so once approved the admin commits the file to the release branch. 

As far as metadata... yes, you can create a version property which would trigger your commit script to disallow a check in of certain files. OF course, those properties would be modifyable for the most part which might be ok if you don't need this to be a security boundary.

BOb
 

Re: stalling commits until approval

[Tucker <ju...@gmail.com>]

On Tue, Jan 26, 2010 at 12:56 PM, Tucker <ju...@gmail.com> wrote:
> Does anyone know of a, relatively, simple way to block commits,
> without approval?  For the sake of context, here's the actual need:
>
> The company I work for has decided (correctly) that we need to keep
> out system configuration scripts (puppet) in Subversion.  Migrating
> all of this is a rather trivial task but adding sanity to changes is
> one of my top priorities.  Since puppet has the power to do "Bad
> Things," when you mess up a config, we'd like to require change
> approval.  The suggestion I've heard, thus far, is to have release and
> development branches and integrate from the dev branch, once a change
> has been approved.  While doable, this isn't the most scalable
> solution.  What I'd like to see is something more like this:
>
> 1) Admin makes a change and attempts to commits
> 2) Pre commit sends out a request for peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the original admin can now commit to release branch
>
> Using dev and release branches, something like this seems feasible:
>
> 1) Admin makes a change and commits to dev branch
> 2) Post commit hook sends email, requesting peer review
> 3) Second admin either approves the change or adds feedback
> 4) Once approved, the change is picked up by a cron script and
> integrated into release branch
>
> Now, where my complete lack of SVN skills show is that I don't know if
> this is possible.  Are there additional tags (META?) that can be added
> to commits, that can make one of these scenarios possible?  Are there
> existing hook recipes, that someone knows of, that could help me along
> the way?  Any insight is appreciated.
>
>
> --
>
> --tucker
>

One last thing:  I thank you all for the input.  I started some
hacking last night and I have the first revision of a python
pre-submit script going.  The pysvn library is a life saver.
Hopefully, when this has matured, I'll be able to release it into the
wild for the world to scrutinize (and tell me how bad I am at code
optimization).

-- 

--tucker