Open Stack

On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote:
[...]
> I usually prefer server side hooks as then I don't have to deploy
> all the developer tools all of the random repos I contribute to
> require all the time. If it can be made server side somehow, thats
> vastly easier to deal with by folks like me or other drive by
> contributors.

Server-side hooks are fine for rejecting a push (if somewhat
inflexible and hard to manage across projects, and in most ways
inferior to equivalent CI jobs), but you don't want them altering
commits as that invalidates any commit signing (in the git commit
-S/--gpg-sign sense, not the -s/--signoff sense) the original
committer may have performed.

> I'm thinking more along the line of, we have a bunch of gate
> blocking tests that ensure some amount of code quality going in.
> But what if we could take it to the next level and have those
> tests actually feed back quality enhancements too, not just saying
> no and without the developer to install extra tools?
[...]

The suggestion to have automation push a revision to a patch you
propose while it's still under review is an interesting one, though
it does bear some resemblance to the server-side hooks problem. The
commit which would be approved and merged at that point isn't
identified as yours. Some attempt could be made to have the
automation masquerade as your identity insofar as forging the
committer details to match the prior patch, but it wouldn't be able
to reproduce your cryptographic signature so *if* you're keen on
OpenPGP-signing your commits, you'll lose that when the auto-revised
version ends up merging instead of your original.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190423/66913f09/attachment.sig>