I'd suggest reverting this as well. It makes your dashboard basically
useless when all of your patches are +1'd, and all of them by a bot.
-- Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Fri, Dec 7, 2012 at 1:58 PM, Derric Atzrott datzr...@alizeepathology.com
wrote:
Why not just add (more) slaves? Computing power is much
cheaper than developer time.
I absolutely agree.
I'm also in agreement on this one. Having tests run after code review
negates
the point of
| I understand the concern, but if we're creating a world
| where tests have to wait for developer review, we're doing
| CI the wrong way around. The whole point of automated
| testing is to minimize the need for human review, so we
| should aim to run as many tests as possible as early as
Le 06/12/12 19:19, Antoine Musso a écrit :
If all works fine tonight, I will configure jenkins-bot so it merges the
Change automatically whenever the test are successful.
Jenkins now automatically merge changes made to mediawiki/core.git that
have received CR+2 and pass all tests. The related
Le 07/12/12 04:56, Sébastien Santoro wrote
snip
This is very disturbing when browsing Gerrit for revisions still to
review and doesn't really give any useful information (as the
important information here would be the verified -1).
Lets open the can of worm here :)
Chad came up with another
On Fri, Dec 7, 2012 at 4:19 PM, Antoine Musso hashar+...@free.fr wrote:
Le 07/12/12 04:56, Sébastien Santoro wrote
snip
This is very disturbing when browsing Gerrit for revisions still to
review and doesn't really give any useful information (as the
important information here would be the
On 12/07/2012 04:19 PM, Antoine Musso wrote:
Le 07/12/12 04:56, Sébastien Santoro wrote
snip
This is very disturbing when browsing Gerrit for revisions still to
review and doesn't really give any useful information (as the
important information here would be the verified -1).
Lets open the
Hello,
Earlier today I have slightly changed our review / test workflow on
mediawiki/core.git . That will let us do more tests and scale things in
the long term.
The new workflow is described on the wiki (including a flowchart):
https://www.mediawiki.org/wiki/Continuous_integration/Workflow
Antoine Musso hashar+...@free.fr wrote:
Earlier today I have slightly changed our review / test workflow on
mediawiki/core.git . That will let us do more tests and scale things in
the long term.
The new workflow is described on the wiki (including a flowchart):
On Thu, Dec 6, 2012 at 10:52 PM, Tim Landscheidt t...@tim-landscheidt.de
wrote:
That is all. The slow unit tests are no more run on patchset submission.
We really need them.
The tests philosophy is there is an issue with this change.
The Jenkins philosophy is automate as most as possible to
Le 06/12/12 22:52, Tim Landscheidt wrote:
Why not just add (more) slaves? Computing power is much
cheaper than developer time.
Erik, everyone and I are eager to add more computing power. We are going
to use Vagrant virtual machines setup as Jenkins slaves. It takes a bit
more engineering to
On 06/12/2012 15:01, Sébastien Santoro wrote:
On Thu, Dec 6, 2012 at 10:52 PM, Tim Landscheidt t...@tim-landscheidt.de
wrote:
That is all. The slow unit tests are no more run on patchset submission.
We really need them.
The tests philosophy is there is an issue with this change.
The
On Thu, Dec 6, 2012 at 7:19 PM, Antoine Musso hashar+...@free.fr wrote:
(...)
If everything is fine, jenkins-bot will vote Code-Review +1 to let
everyone know that the change look fine. Else, it will vote Verified -1
preventing the patchset from being submitted.
Could you, pending the end of
13 matches
Mail list logo
