On 2013-03-22 21:08:18 + (+), Jeremy Stanley wrote:
[...]
> watches the Gerrit event stream and triggers jobs in Jenkins as a
> result of matching again patterns defined a YAML configuration
> file
[...]
Yeesh. I clearly shouldn't write E-mail when I'm rushing off to eat.
What I meant to s
On 2013-03-22 21:44:21 +0100 (+0100), Guido Günther wrote:
> Gerrit's Jenkins integration is awesome.
[...]
OpenStack CI has some additional tools which help avoid the need to
interact directly with Jenkins too much. There's Zuul (the
gatekeeper) which watches the Gerrit event stream and triggers
On Fri, Mar 08, 2013 at 02:52:48PM +0100, Thomas Koch wrote:
> Hi Daniel et al,
>
> I'm also thinking a lot about how to improve Debian by improving our Git
> tooling. Therefor I'm packaging Gerrit (#589436). But gerrit and its
> dependencies is a big project...
>
> Now that Git slowly becomes
Hi Tollef,
Tollef Fog Heen writes:
> Buildbot is pretty crap at managing slaves that disappear and come back
> and such.
This works fine for me, I have never had any trouble with that (and yes,
my build slaves have disconnected/reconnected quite a few times). Using
buildbot since more than a year
]] Thomas Goirand
> Did anyone try buildbot? It might be better for what I need.
Buildbot is pretty crap at managing slaves that disappear and come back
and such.
> I quite disliked the fact that most of Jenkins is done through
> a web GUI, which was in fact, more a nuisance than anything
> els
Stefano Zacchiroli debian.org> writes:
> Related to this, there is also the risk that a user will ssh on alioth
> and rm the repository (accidentally or not). Do we have any kind of
> protection against that? (e.g. backups we can access to without
> bothering the alioth admins, or a way to give g
]] Thomas Goirand
> I wasn't discussing what can be done for backing up a Git repository,
> I was asking what is *currently installed* in production as a backup
> for Alioth.
da-backup. Look at /etc/da-backup/* for the configuration.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky a
On 2013-03-09 23:33:47 +0800 (+0800), Thomas Goirand wrote:
[...]
> I also need to understand how to secure Jenkins. Because
> by default, it's impressive how much Jenkins is a security
> hole where you can execute any command. I was tempted
> to file a bug report against the package because of it.
On 03/09/2013 12:36 AM, PICCA Frédéric-Emmanuel wrote:
>> I start to really love the CI thing. I first invested a bit of
>> time in setting-up everything,
> do you have a step by step cookbook for your setup.
> Maybe on the debian wiki ?
Unfortunately, no. But it's really easier than what I thought
On 2013-03-08 12:44:36 -0800 (-0800), Russ Allbery wrote:
> Thank you very much for working on this! We use Gerrit extensively but so
> far just haven't packaged it because it was too intimidating.
Agreed, if Gerrit gets packaged in Debian/Ubuntu I'll likely push
OpenStack to start using DEBs of
Thomas Koch writes:
> I'm also thinking a lot about how to improve Debian by improving our Git
> tooling. Therefor I'm packaging Gerrit (#589436). But gerrit and its
> dependencies is a big project...
Thank you very much for working on this! We use Gerrit extensively but so
far just haven't pac
> I love what Michael Prokop did and documented here:
> http://jenkins-debian-glue.org/
> Jenkins + Debian packaging using cowbuilder
> The code is very clean and easy to hack.
Thanks, yes it looks great.
Cheers
Fred
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subje
On 08/03/2013 17:36, PICCA Frédéric-Emmanuel wrote:
>> I start to really love the CI thing. I first invested a bit of
>> time in setting-up everything,
>
> do you have a step by step cookbook for your setup.
> Maybe on the debian wiki ?
I love what Michael Prokop did and documented here:
http://j
> I start to really love the CI thing. I first invested a bit of
> time in setting-up everything,
do you have a step by step cookbook for your setup.
Maybe on the debian wiki ?
Cheers
Frederic
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
On 03/08/2013 10:34 PM, Jeremy Stanley wrote:
> On 2013-03-08 14:52:48 +0100 (+0100), Thomas Koch wrote:
> [...]
>> http://openstack-ci.github.com/publications/
> [...]
>
> I'm one of the core developers for the team which manages all that
> tooling and integration for the OpenStack Project, so I'm
On 2013-03-08 14:52:48 +0100 (+0100), Thomas Koch wrote:
[...]
> http://openstack-ci.github.com/publications/
[...]
I'm one of the core developers for the team which manages all that
tooling and integration for the OpenStack Project, so I'm happy to
discuss some of the nitty-gritty details, any go
Hi Daniel et al,
I'm also thinking a lot about how to improve Debian by improving our Git
tooling. Therefor I'm packaging Gerrit (#589436). But gerrit and its
dependencies is a big project...
Now that Git slowly becomes the de facto standard VCS for Debian[1]
(resistance is futile) it might be
On Mon, Mar 04, 2013 at 12:45:14AM +0800, Paul Wise wrote:
> On Sun, Mar 3, 2013 at 11:21 PM, Thomas Goirand wrote:
> > So yes, I would think having a safe, backup of Alioth is important.
> > Now, what worries me is that I didn't read any of the Alioth admins
> > explaining what is currently in pro
On Sun, Mar 3, 2013 at 11:21 PM, Thomas Goirand wrote:
> So yes, I would think having a safe, backup of Alioth is important.
> Now, what worries me is that I didn't read any of the Alioth admins
> explaining what is currently in production. I've searched, and the
> only info I found was hosted pro
On 03/01/2013 02:20 AM, Daniel Pocock wrote:
>
> DD access is also an `all or nothing' scenario, and it is tightly
> controlled in other ways.
>
> What I was anticipating is how we can provide more access for upstreams
> and other non-DDs using the guest account mechanism or potentially some
> kind
On 03/03/2013 12:51 AM, Wouter Verhelst wrote:
> On Thu, Feb 28, 2013 at 11:07:22AM +0100, Stefano Zacchiroli wrote:
>> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>>> Has anybody had experience controlling access to git repositories, for
>>> example, to give users access but pre
On Thu, Feb 28, 2013 at 11:07:22AM +0100, Stefano Zacchiroli wrote:
> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
> > Has anybody had experience controlling access to git repositories, for
> > example, to give users access but prevent some of the following
> > dangerous operation
On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>
>
> There was recently some discussion in pkg-javascript about how to give
> more people access to the VCS (e.g. keeping the git repositories
> logically organised under the pkg-javascript tree, but making write
> access available t
Hello,
On Fri, 01 Mar 2013 18:48:51 +0800
Thomas Goirand wrote:
> On 02/28/2013 08:33 PM, Andrew Shadura wrote:
> > we'd have both hg and git in one unified interface.
> That is a very nice feature. I saw few sites having that, for example
> bitbucket, unfortunatley, bitbucket doesn't allow git
On 03/01/2013 09:34 PM, Cyril Brulebois wrote:
> Thomas Goirand (01/03/2013):
>> I wasn't discussing what can be done for backing up a Git repository,
>> I was asking what is *currently installed* in production as a backup
>> for Alioth.
> Why are you asking debian-devel@ instead of asking the act
Thomas Goirand (01/03/2013):
> I wasn't discussing what can be done for backing up a Git repository,
> I was asking what is *currently installed* in production as a backup
> for Alioth.
Why are you asking debian-devel@ instead of asking the actual admins?
(http://wiki.debian.org/Alioth#Maintenan
On 03/01/2013 07:21 PM, Dmitrijs Ledkovs wrote:
> On 1 March 2013 10:54, Thomas Goirand wrote:
>> On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote:
>>> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
Has anybody had experience controlling access to git repositories, for
ex
On 1 March 2013 10:54, Thomas Goirand wrote:
> On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote:
>> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>>> Has anybody had experience controlling access to git repositories, for
>>> example, to give users access but prevent some of the fo
On 02/28/2013 06:07 PM, Stefano Zacchiroli wrote:
> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>> Has anybody had experience controlling access to git repositories, for
>> example, to give users access but prevent some of the following
>> dangerous operations?
> Related to this,
On 02/28/2013 08:33 PM, Andrew Shadura wrote:
> we'd have both hg and git in one unified interface.
That is a very nice feature. I saw few sites having that, for example
bitbucket, unfortunatley, bitbucket doesn't allow git anonymous
checkout over http (it's only available with hg, if I understood
On Donnerstag, 28. Februar 2013, Holger Levsen wrote:
> signed commits, so you can identify unwanted bits and clean up in the very
> care case that's actually needed?
^^ rare case
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
On Thu, 28 Feb 2013, Holger Levsen wrote:
> signed commits, so you can identify unwanted bits and clean up in the very
> care case that's actually needed?
Indeed. Secure git workflows are possible, although it is a relatively new
development. Signed commits and pull requests are a very big part
Hi,
signed commits, so you can identify unwanted bits and clean up in the very
care case that's actually needed?
cheer,s
Holger
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: htt
On Thu, Feb 28, 2013 at 04:01:34PM +0600, Andrey Rahmatullin wrote:
> On Thu, Feb 28, 2013 at 10:45:35AM +0100, Tollef Fog Heen wrote:
> > > Has anybody had experience controlling access to git repositories, for
> > > example, to give users access but prevent some of the following
> > > dangerous o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 28/02/13 20:20, Jonas Smedegaard wrote:
> Quoting Daniel Pocock (2013-02-28 19:20:09)
>> On 28/02/13 13:15, Simon McVittie wrote:
>>> On 28/02/13 09:39, Daniel Pocock wrote:
Has anybody had experience controlling access to git
repositori
Quoting Daniel Pocock (2013-02-28 19:20:09)
> On 28/02/13 13:15, Simon McVittie wrote:
> > On 28/02/13 09:39, Daniel Pocock wrote:
> >> Has anybody had experience controlling access to git repositories,
> >> for example, to give users access but prevent some of the following
> >> dangerous operat
On 28/02/13 13:15, Simon McVittie wrote:
> On 28/02/13 09:39, Daniel Pocock wrote:
>> Has anybody had experience controlling access to git repositories, for
>> example, to give users access but prevent some of the following
>> dangerous operations?
>
> If you look at it from the appropriate angle
On Thu, 28 Feb 2013 12:51:33 +0100, Arno Töll wrote:
> On 28.02.2013 11:07, Stefano Zacchiroli wrote:
> > On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
> >> Has anybody had experience controlling access to git repositories, for
> >> example, to give users access but prevent some o
Hello.
On 28 February 2013 12:51, Arno Töll wrote:
> Having that said the risk is real and it may be time to reconsider some
> choices including the use of Alioth itself for those who do not believe
> in openness. Chances are #700630 is going to rescue us all on that.
> Maybe we could set-up our
On 28/02/13 09:39, Daniel Pocock wrote:
> Has anybody had experience controlling access to git repositories, for
> example, to give users access but prevent some of the following
> dangerous operations?
Do you consider this to be a strong security measure against malicious
changes, or a weak safet
Hi,
On 28.02.2013 11:07, Stefano Zacchiroli wrote:
> On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
>> Has anybody had experience controlling access to git repositories, for
>> example, to give users access but prevent some of the following
>> dangerous operations?
>
> Related to
On Thu, Feb 28, 2013 at 10:39:26AM +0100, Daniel Pocock wrote:
> Has anybody had experience controlling access to git repositories, for
> example, to give users access but prevent some of the following
> dangerous operations?
Related to this, there is also the risk that a user will ssh on alioth
a
On Thu, Feb 28, 2013 at 10:45:35AM +0100, Tollef Fog Heen wrote:
> > Has anybody had experience controlling access to git repositories, for
> > example, to give users access but prevent some of the following
> > dangerous operations?
> >
> > - prevent users pushing with the `--force' option
> > (fr
On 28 February 2013 09:39, Daniel Pocock wrote:
>
>
> There was recently some discussion in pkg-javascript about how to give
> more people access to the VCS (e.g. keeping the git repositories
> logically organised under the pkg-javascript tree, but making write
> access available to all DDs + alio
]] Daniel Pocock
> Has anybody had experience controlling access to git repositories, for
> example, to give users access but prevent some of the following
> dangerous operations?
>
> - prevent users pushing with the `--force' option
> (from the man page for git-push: "This can cause the remote r
There was recently some discussion in pkg-javascript about how to give
more people access to the VCS (e.g. keeping the git repositories
logically organised under the pkg-javascript tree, but making write
access available to all DDs + alioth guest users and not just those in
the pkg-javascript UNI
46 matches
Mail list logo
