[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH 00/12] Plannings for secure-testing repository migration to git



Hi,
On Thu, Dec 28, 2017 at 09:13:09AM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> On Wed, Dec 27, 2017 at 11:32:53PM +0100, Salvatore Bonaccorso wrote:
> > 1/ desire of commit mailinglist
> 
> Would there be objection to switch those to
> debian-security-tracker@l.d.o? A dedicated list IHMO would be better
> to distinguish between the commit review list and the general
> discussion/bug list.
> 
> > 2/ how to do the updates with the sectracker role account specific to
> > some files (e.g. automatic updates, data/CVE/list update, dsa
> > canditate finding).
> 
> Btw, 3/ is there a way to force a pre-commit/pre-push action with git
> repositories (so client side hooks forced on every cloned repository)
> which would run 'make check-syntax' before we push something? For the
> subversion repository this was implemented with a pre-commit svn hook,
> which called for changes with bin/check-syntax, or
> bin/check-new-issues -c (for the data/embedded-code-copies file).
> 
> I guess the short answer is 'no'.

We could provide a pre-commit hook:

    https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks

they're not enforced though. User would have to set it up via

    ln -s bin/pre-commit .git/hooks/pre-commit

(which we could put into a "bin/setup-repo"). Since the hook can
identify changed files we could only run tests on changed files so it
would be reasonably fast. I'll have a look.

> I got the reply for Salsa, for the custom_hooks referring to
> https://docs.gitlab.com/ce/administration/custom_hooks.html but as far
> I understand those are server-side running hooks.

Will it be possible for us to add such a hook on salsa? AFAIK adding
these needs admin permissions on the GitLab instance. Having an
in-flight syntax-check is a nice feature of the current setup which
would be good to preserve.
While we could set up a something that tests every merge request using
 merge requests looks like overkill here.

Cheers,
 -- Guido


Reply to: