[jitsi-dev] protected branches and mandatory peer reviews


#1

Hey all,

So, while talking to different people there seems to be a rough consensus around the fact that we would benefit if we made peer-reviews an almost mandatory part of our process.

There are *maaany* different opinions about exactly how we should do this so I am going to abuse my dictator position a bit and kickstart the process.

In an hour, I will go and enable the protected branches feature on Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something else if I feel so inclined :wink: ).

I will not be setting it on Jitsi for now because we are struggling enough for resources there to make the process even harder.

What I would like to get from everyone is feedback on how you think this is working out or in case you think that this is somehow going to be the end of the world for whatever reason.

Remember: this is not set in stone, we can always undo it if we find it is suboptimal.

So ... here goes nothing!

Emil

路路路

--
https://jitsi.org


#2

To clarify, does this include lib-jitsi-meet or not?

Regards,
Boris

路路路

On 17/02/16 15:44, Emil Ivov wrote:

Hey all,

So, while talking to different people there seems to be a rough
consensus around the fact that we would benefit if we made peer-reviews
an almost mandatory part of our process.

There are *maaany* different opinions about exactly how we should do
this so I am going to abuse my dictator position a bit and kickstart the
process.

In an hour, I will go and enable the protected branches feature on Meet,
libjitsi, JVB, Jicofo and Jigasi (and maybe something else if I feel so
inclined :wink: ).


#3

So, while talking to different people there seems to be a rough
consensus around the fact that we would benefit if we made peer-reviews
an almost mandatory part of our process.

There are *maaany* different opinions about exactly how we should do
this so I am going to abuse my dictator position a bit and kickstart the
process.

In an hour, I will go and enable the protected branches feature on Meet,
libjitsi, JVB, Jicofo and Jigasi (and maybe something else if I feel so
inclined :wink: ).

How is that formally going to work? There are no status checks on the branches/pull requests (at least not for libjitsi). So all a protected branch on Github will do is preventing a force-push to or deletion of master (which hasn't been an issue so far). Anyone with write access will still be able to push (or merge) without following the rules.

I will not be setting it on Jitsi for now because we are struggling
enough for resources there to make the process even harder.

I'd be glad if there was anything to commit or review at all :frowning:

What I would like to get from everyone is feedback on how you think this
is working out or in case you think that this is somehow going to be the
end of the world for whatever reason.

I guess it's a good thing, but then the pull requests and commit messages should start by being more descriptive and follow the Git rules (max. 50 chars for the first line, detailed explanation on the following lines with max 76 chars).

Remember: this is not set in stone, we can always undo it if we find it
is suboptimal.

So ... here goes nothing!

Emil

Ingo


#4

So, while talking to different people there seems to be a rough
consensus around the fact that we would benefit if we made
peer-reviews an almost mandatory part of our process.

There are *maaany* different opinions about exactly how we should
do this so I am going to abuse my dictator position a bit and
kickstart the process.

In an hour, I will go and enable the protected branches feature on
Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something else if
I feel so inclined :wink: ).

How is that formally going to work? There are no status checks on the
branches/pull requests (at least not for libjitsi). So all a
protected branch on Github will do is preventing a force-push to or
deletion of master (which hasn't been an issue so far). Anyone with
write access will still be able to push (or merge) without following
the rules.

Eeer ... yes ... apparently you are right and I had misunderstood the protected branches feature.

Ah well ... so it sounds like this would have to be a policy for now.

I will not be setting it on Jitsi for now because we are
struggling enough for resources there to make the process even
harder.

I'd be glad if there was anything to commit or review at all :frowning:

Good point!

What I would like to get from everyone is feedback on how you think
this is working out or in case you think that this is somehow going
to be the end of the world for whatever reason.

I guess it's a good thing, but then the pull requests and commit
messages should start by being more descriptive and follow the Git
rules (max. 50 chars for the first line, detailed explanation on the
following lines with max 76 chars).

Agreed. Hopefully that would be one of the good side effects resulting from the policy.

Thanks for sharing!

Emil

路路路

On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:

Remember: this is not set in stone, we can always undo it if we
find it is suboptimal.

So ... here goes nothing!

Emil

Ingo

_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#5

Hey all,

So, while talking to different people there seems to be a rough
consensus around the fact that we would benefit if we made peer-reviews
an almost mandatory part of our process.

There are *maaany* different opinions about exactly how we should do
this so I am going to abuse my dictator position a bit and kickstart the
process.

In an hour, I will go and enable the protected branches feature on Meet,
libjitsi, JVB, Jicofo and Jigasi (and maybe something else if I feel so
inclined :wink: ).

To clarify, does this include lib-jitsi-meet or not?

Yes, it does!

Emil

路路路

On Wednesday, 17 February 2016, Boris Grozev <boris@jitsi.org> wrote:

On 17/02/16 15:44, Emil Ivov wrote:

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
sent from my mobile


#6

Hi all,

Just wanted to check with this topic for otr4j, as we never really
talked about that project specifically.

I would prefer protecting otr4j as well, if it isn't already.

Furthermore, see in line ...

So, while talking to different people there seems to be a rough
consensus around the fact that we would benefit if we made
peer-reviews an almost mandatory part of our process.

There are *maaany* different opinions about exactly how we should
do this so I am going to abuse my dictator position a bit and
kickstart the process.

In an hour, I will go and enable the protected branches feature on
Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something else if
I feel so inclined :wink: ).

How is that formally going to work? There are no status checks on the
branches/pull requests (at least not for libjitsi). So all a
protected branch on Github will do is preventing a force-push to or
deletion of master (which hasn't been an issue so far). Anyone with
write access will still be able to push (or merge) without following
the rules.

Eeer ... yes ... apparently you are right and I had misunderstood the
protected branches feature.

Ah well ... so it sounds like this would have to be a policy for now.

Maybe I missed it, but what would the workflow look like? Prepare pull
request and wait for approval? (Assign to someone in advance? .. in case
of otr4j, that would probably be @gpolitis :P)

Kind regards,
Danny

路路路

On 18-02-16 03:23, Emil Ivov wrote:

On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:

[...]


#7

Hi Danny,

Thank you for bringing this up! I just enabled branch protection for otr4j
master. As for mandatory PRs (as in Peer Review and Pull Request), it's
already supposed to work this way and it's stated in the "contributing"
section of the readme.md.

Best,
George

路路路

On Mon, Feb 29, 2016 at 1:50 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi all,

Just wanted to check with this topic for otr4j, as we never really
talked about that project specifically.

I would prefer protecting otr4j as well, if it isn't already.

Furthermore, see in line ...

On 18-02-16 03:23, Emil Ivov wrote:
> On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:
>>> So, while talking to different people there seems to be a rough
>>> consensus around the fact that we would benefit if we made
>>> peer-reviews an almost mandatory part of our process.
>>>
>>> There are *maaany* different opinions about exactly how we should
>>> do this so I am going to abuse my dictator position a bit and
>>> kickstart the process.
>>>
>>> In an hour, I will go and enable the protected branches feature on
>>> Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something else if
>>> I feel so inclined :wink: ).
>>
>> How is that formally going to work? There are no status checks on the
>> branches/pull requests (at least not for libjitsi). So all a
>> protected branch on Github will do is preventing a force-push to or
>> deletion of master (which hasn't been an issue so far). Anyone with
>> write access will still be able to push (or merge) without following
>> the rules.
>
> Eeer ... yes ... apparently you are right and I had misunderstood the
> protected branches feature.
>
> Ah well ... so it sounds like this would have to be a policy for now.

Maybe I missed it, but what would the workflow look like? Prepare pull
request and wait for approval? (Assign to someone in advance? .. in case
of otr4j, that would probably be @gpolitis :P)

Kind regards,
Danny

> [...]

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hi Danny,

Thank you for bringing this up! I just enabled branch protection for
otr4j master. As for mandatory PRs (as in Peer Review and Pull
Request), it's already supposed to work this way and it's stated in
the "contributing" section of the readme.md <http://readme.md>.

Hmm... now that I am reading the text it begins to dawn on me. You're
right. I completely forgot about it :stuck_out_tongue:

Thanks!
Danny

路路路

On 29-02-16 21:00, George Politis wrote:

Best,
George

On Mon, Feb 29, 2016 at 1:50 PM, Danny van Heumen > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

聽聽聽聽Hi all,

聽聽聽聽Just wanted to check with this topic for otr4j, as we never really
聽聽聽聽talked about that project specifically.

聽聽聽聽I would prefer protecting otr4j as well, if it isn't already.

聽聽聽聽Furthermore, see in line ...

聽聽聽聽On 18-02-16 03:23, Emil Ivov wrote:
聽聽聽聽> On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:
聽聽聽聽>>> So, while talking to different people there seems to be a rough
聽聽聽聽>>> consensus around the fact that we would benefit if we made
聽聽聽聽>>> peer-reviews an almost mandatory part of our process.
聽聽聽聽>>>
聽聽聽聽>>> There are *maaany* different opinions about exactly how we should
聽聽聽聽>>> do this so I am going to abuse my dictator position a bit and
聽聽聽聽>>> kickstart the process.
聽聽聽聽>>>
聽聽聽聽>>> In an hour, I will go and enable the protected branches feature on
聽聽聽聽>>> Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something
聽聽聽聽else if
聽聽聽聽>>> I feel so inclined :wink: ).
聽聽聽聽>>
聽聽聽聽>> How is that formally going to work? There are no status checks
聽聽聽聽on the
聽聽聽聽>> branches/pull requests (at least not for libjitsi). So all a
聽聽聽聽>> protected branch on Github will do is preventing a force-push to or
聽聽聽聽>> deletion of master (which hasn't been an issue so far). Anyone with
聽聽聽聽>> write access will still be able to push (or merge) without
聽聽聽聽following
聽聽聽聽>> the rules.
聽聽聽聽>
聽聽聽聽> Eeer ... yes ... apparently you are right and I had
聽聽聽聽misunderstood the
聽聽聽聽> protected branches feature.
聽聽聽聽>
聽聽聽聽> Ah well ... so it sounds like this would have to be a policy for
聽聽聽聽now.

聽聽聽聽Maybe I missed it, but what would the workflow look like? Prepare pull
聽聽聽聽request and wait for approval? (Assign to someone in advance? ..
聽聽聽聽in case
聽聽聽聽of otr4j, that would probably be @gpolitis :P)

聽聽聽聽Kind regards,
聽聽聽聽Danny

聽聽聽聽> [...]

聽聽聽聽_______________________________________________
聽聽聽聽dev mailing list
聽聽聽聽dev@jitsi.org <mailto:dev@jitsi.org>
聽聽聽聽Unsubscribe instructions and other list options:
聽聽聽聽http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Nevertheless thank you for bringing this up because now we have branch
protection :slight_smile: We discussed and adopted mandatory PRs a little more than a
year ago (among other things that we could not adopt, like CLAs etc.)
https://github.com/jitsi/otr4j/issues/15.

路路路

On Mon, Feb 29, 2016 at 2:03 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

On 29-02-16 21:00, George Politis wrote:
> Hi Danny,
>
> Thank you for bringing this up! I just enabled branch protection for
> otr4j master. As for mandatory PRs (as in Peer Review and Pull
> Request), it's already supposed to work this way and it's stated in
> the "contributing" section of the readme.md <http://readme.md>.

Hmm... now that I am reading the text it begins to dawn on me. You're
right. I completely forgot about it :stuck_out_tongue:

Thanks!
Danny

>
> Best,
> George
>
> On Mon, Feb 29, 2016 at 1:50 PM, Danny van Heumen > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
>
> Hi all,
>
> Just wanted to check with this topic for otr4j, as we never really
> talked about that project specifically.
>
> I would prefer protecting otr4j as well, if it isn't already.
>
> Furthermore, see in line ...
>
> On 18-02-16 03:23, Emil Ivov wrote:
> > On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:
> >>> So, while talking to different people there seems to be a rough
> >>> consensus around the fact that we would benefit if we made
> >>> peer-reviews an almost mandatory part of our process.
> >>>
> >>> There are *maaany* different opinions about exactly how we should
> >>> do this so I am going to abuse my dictator position a bit and
> >>> kickstart the process.
> >>>
> >>> In an hour, I will go and enable the protected branches feature
on
> >>> Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something
> else if
> >>> I feel so inclined :wink: ).
> >>
> >> How is that formally going to work? There are no status checks
> on the
> >> branches/pull requests (at least not for libjitsi). So all a
> >> protected branch on Github will do is preventing a force-push to
or
> >> deletion of master (which hasn't been an issue so far). Anyone
with
> >> write access will still be able to push (or merge) without
> following
> >> the rules.
> >
> > Eeer ... yes ... apparently you are right and I had
> misunderstood the
> > protected branches feature.
> >
> > Ah well ... so it sounds like this would have to be a policy for
> now.
>
> Maybe I missed it, but what would the workflow look like? Prepare
pull
> request and wait for approval? (Assign to someone in advance? ..
> in case
> of otr4j, that would probably be @gpolitis :P)
>
> Kind regards,
> Danny
>
>
> > [...]
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

A small correction to my previous message, I meant to write "like *change*
CLAs".

路路路

On Mon, Feb 29, 2016 at 2:13 PM, George Politis <gp@jitsi.org> wrote:

Nevertheless thank you for bringing this up because now we have branch
protection :slight_smile: We discussed and adopted mandatory PRs a little more than a
year ago (among other things that we could not adopt, like CLAs etc.)
https://github.com/jitsi/otr4j/issues/15.

On Mon, Feb 29, 2016 at 2:03 PM, Danny van Heumen <danny@dannyvanheumen.nl > > wrote:

On 29-02-16 21:00, George Politis wrote:
> Hi Danny,
>
> Thank you for bringing this up! I just enabled branch protection for
> otr4j master. As for mandatory PRs (as in Peer Review and Pull
> Request), it's already supposed to work this way and it's stated in
> the "contributing" section of the readme.md <http://readme.md>.

Hmm... now that I am reading the text it begins to dawn on me. You're
right. I completely forgot about it :stuck_out_tongue:

Thanks!
Danny

>
> Best,
> George
>
> On Mon, Feb 29, 2016 at 1:50 PM, Danny van Heumen >> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
>
> Hi all,
>
> Just wanted to check with this topic for otr4j, as we never really
> talked about that project specifically.
>
> I would prefer protecting otr4j as well, if it isn't already.
>
> Furthermore, see in line ...
>
> On 18-02-16 03:23, Emil Ivov wrote:
> > On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:
> >>> So, while talking to different people there seems to be a rough
> >>> consensus around the fact that we would benefit if we made
> >>> peer-reviews an almost mandatory part of our process.
> >>>
> >>> There are *maaany* different opinions about exactly how we
should
> >>> do this so I am going to abuse my dictator position a bit and
> >>> kickstart the process.
> >>>
> >>> In an hour, I will go and enable the protected branches feature
on
> >>> Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something
> else if
> >>> I feel so inclined :wink: ).
> >>
> >> How is that formally going to work? There are no status checks
> on the
> >> branches/pull requests (at least not for libjitsi). So all a
> >> protected branch on Github will do is preventing a force-push to
or
> >> deletion of master (which hasn't been an issue so far). Anyone
with
> >> write access will still be able to push (or merge) without
> following
> >> the rules.
> >
> > Eeer ... yes ... apparently you are right and I had
> misunderstood the
> > protected branches feature.
> >
> > Ah well ... so it sounds like this would have to be a policy for
> now.
>
> Maybe I missed it, but what would the workflow look like? Prepare
pull
> request and wait for approval? (Assign to someone in advance? ..
> in case
> of otr4j, that would probably be @gpolitis :P)
>
> Kind regards,
> Danny
>
>
> > [...]
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hi all,

We added automatic testing of the newly created PRs. When the PR is
from on of the developers it is executed automatically and the fail or
success result is visible in the PR.
If the creator of the PR is not developer a comment is added to the
PR: "Can one of the developers verify this PR?"
Every developer can whitelist a user for a particular project by
adding a comment containing 'add to whitelist'. This way that user's
PRs will be automatically tested now on for that project.
If you update the PR, tests will be automatically scheduled again.
If you want to force a test any developer can add a comment containing
"ok to test".
Changes are checked every 10mins., and for now jobs are in a queue.
Later we will add parallel testing of PRs, but for now it may take
some time :slight_smile:

And now the complicated part and the one rule that we implemented for
this testing mechanism.
If you have PRs in different projects which depends on each other and
need to be tested together you need to create both branches with the
same name and push them together so when testing starts it will find
that there are PRs with same branch name and will test them together.

Comment message strings are configurable and we can change them. For
now I've changed the: "Can one of the admins verify this patch?" to be
"Can one of the developers verify this PR?"

Any questions or recommendations are welcome.

Regards
damencho

路路路

On Mon, Feb 29, 2016 at 2:19 PM, George Politis <gp@jitsi.org> wrote:

A small correction to my previous message, I meant to write "like *change*
CLAs".

On Mon, Feb 29, 2016 at 2:13 PM, George Politis <gp@jitsi.org> wrote:

Nevertheless thank you for bringing this up because now we have branch
protection :slight_smile: We discussed and adopted mandatory PRs a little more than a
year ago (among other things that we could not adopt, like CLAs etc.)
https://github.com/jitsi/otr4j/issues/15.

On Mon, Feb 29, 2016 at 2:03 PM, Danny van Heumen >> <danny@dannyvanheumen.nl> wrote:

On 29-02-16 21:00, George Politis wrote:
> Hi Danny,
>
> Thank you for bringing this up! I just enabled branch protection for
> otr4j master. As for mandatory PRs (as in Peer Review and Pull
> Request), it's already supposed to work this way and it's stated in
> the "contributing" section of the readme.md <http://readme.md>.

Hmm... now that I am reading the text it begins to dawn on me. You're
right. I completely forgot about it :stuck_out_tongue:

Thanks!
Danny

>
> Best,
> George
>
> On Mon, Feb 29, 2016 at 1:50 PM, Danny van Heumen >>> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
>
> Hi all,
>
> Just wanted to check with this topic for otr4j, as we never really
> talked about that project specifically.
>
> I would prefer protecting otr4j as well, if it isn't already.
>
> Furthermore, see in line ...
>
> On 18-02-16 03:23, Emil Ivov wrote:
> > On 17.02.16 谐. 16:02, Ingo Bauersachs wrote:
> >>> So, while talking to different people there seems to be a rough
> >>> consensus around the fact that we would benefit if we made
> >>> peer-reviews an almost mandatory part of our process.
> >>>
> >>> There are *maaany* different opinions about exactly how we
> should
> >>> do this so I am going to abuse my dictator position a bit and
> >>> kickstart the process.
> >>>
> >>> In an hour, I will go and enable the protected branches feature
> on
> >>> Meet, libjitsi, JVB, Jicofo and Jigasi (and maybe something
> else if
> >>> I feel so inclined :wink: ).
> >>
> >> How is that formally going to work? There are no status checks
> on the
> >> branches/pull requests (at least not for libjitsi). So all a
> >> protected branch on Github will do is preventing a force-push to
> or
> >> deletion of master (which hasn't been an issue so far). Anyone
> with
> >> write access will still be able to push (or merge) without
> following
> >> the rules.
> >
> > Eeer ... yes ... apparently you are right and I had
> misunderstood the
> > protected branches feature.
> >
> > Ah well ... so it sounds like this would have to be a policy for
> now.
>
> Maybe I missed it, but what would the workflow look like? Prepare
> pull
> request and wait for approval? (Assign to someone in advance? ..
> in case
> of otr4j, that would probably be @gpolitis :P)
>
> Kind regards,
> Danny
>
>
> > [...]
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#12

Hey Damencho, this is awesome! Is there a way to prevent tests from being run for a particular PR (when I know they are going to fail)?

Boris

路路路

On 04/03/16 13:16, Damian Minkov wrote:

Hi all,

We added automatic testing of the newly created PRs. When the PR is
from on of the developers it is executed automatically and the fail or
success result is visible in the PR.
If the creator of the PR is not developer a comment is added to the
PR: "Can one of the developers verify this PR?"
Every developer can whitelist a user for a particular project by
adding a comment containing 'add to whitelist'. This way that user's
PRs will be automatically tested now on for that project.
If you update the PR, tests will be automatically scheduled again.
If you want to force a test any developer can add a comment containing
"ok to test".
Changes are checked every 10mins., and for now jobs are in a queue.
Later we will add parallel testing of PRs, but for now it may take
some time :slight_smile:

And now the complicated part and the one rule that we implemented for
this testing mechanism.
If you have PRs in different projects which depends on each other and
need to be tested together you need to create both branches with the
same name and push them together so when testing starts it will find
that there are PRs with same branch name and will test them together.

Comment message strings are configurable and we can change them. For
now I've changed the: "Can one of the admins verify this patch?" to be
"Can one of the developers verify this PR?"

Any questions or recommendations are welcome.


#13

Hi,

There is a mention of a comment for skipping tests - "skip ci".
Its description is: "When filled, commenting this phrase in the pull
request body will not trigger a build."

I've also disabled the "Can one of the developers verify this PR?"
comment to be automatically added to every PR from non whitelisted
user.
Sorry for polluting all PRs.

Regards
damencho

路路路

On Fri, Mar 4, 2016 at 1:48 PM, Boris Grozev <boris@jitsi.org> wrote:

On 04/03/16 13:16, Damian Minkov wrote:

Hi all,

We added automatic testing of the newly created PRs. When the PR is
from on of the developers it is executed automatically and the fail or
success result is visible in the PR.
If the creator of the PR is not developer a comment is added to the
PR: "Can one of the developers verify this PR?"
Every developer can whitelist a user for a particular project by
adding a comment containing 'add to whitelist'. This way that user's
PRs will be automatically tested now on for that project.
If you update the PR, tests will be automatically scheduled again.
If you want to force a test any developer can add a comment containing
"ok to test".
Changes are checked every 10mins., and for now jobs are in a queue.
Later we will add parallel testing of PRs, but for now it may take
some time :slight_smile:

And now the complicated part and the one rule that we implemented for
this testing mechanism.
If you have PRs in different projects which depends on each other and
need to be tested together you need to create both branches with the
same name and push them together so when testing starts it will find
that there are PRs with same branch name and will test them together.

Comment message strings are configurable and we can change them. For
now I've changed the: "Can one of the admins verify this patch?" to be
"Can one of the developers verify this PR?"

Any questions or recommendations are welcome.

Hey Damencho, this is awesome! Is there a way to prevent tests from being
run for a particular PR (when I know they are going to fail)?

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev