Last modified: 2012-10-11 17:28:25 UTC
See Gerrit change #27389
TODO for Gerrit/Jenkins admin: rebase all patchsets submitted meanwhile.
Fixed with Gerrit change #27395 which makes the test assert that <title /> contains {{SITENAME}}, aka that it is not expanded.
(In reply to comment #1) > TODO for Gerrit/Jenkins admin: rebase all patchsets submitted meanwhile. Jenkins always executes tests based on the latest master and merging the gerrit change on top of that (it doesn't test gerrit changes with the state/HEAD as they were submitted). Which is by design, so that should be fine.
Oh, by the way, how come that change was merged in the first place, why isn't there a jenkins bot failure there?
The change was back from April. That is the only time the test suite has been run. I did not really investigate the root cause, I just fixed the test and merged it. It is on my todo list to run tests before merging so we actually are gating master ;-]
(In reply to comment #5) > The change was back from April. That is the only time the test suite has been > run. I did not really investigate the root cause, I just fixed the test and > merged it. > > It is on my todo list to run tests before merging so we actually are gating > master ;-] You're referring to Ief0bdd10ad882e, right ? It was rebased in October, and merged with a forced Verified:+2.
> It was rebased in October, and merged with a forced Verified:+2. Indeed, patchset 5 (a rebase) is the broken change. Should have waited for tests to finish before merging in :-]
(In reply to comment #7) > > It was rebased in October, and merged with a forced Verified:+2. > > Indeed, patchset 5 (a rebase) is the broken change. Should have waited for > tests to finish before merging in :-] What if a merge was done without a rebase?
(In reply to comment #8) > (In reply to comment #7) > > > It was rebased in October, and merged with a forced Verified:+2. > > > > Indeed, patchset 5 (a rebase) is the broken change. Should have waited for > > tests to finish before merging in :-] > > What if a merge was done without a rebase? Yes, in that case if might have gone wrong regardless (assuming no merge conflict). Which is exactly why we intended from the beginning[1] to run tests on-mergesubmit as opposed to on-push. This is the next step in the continuous integration plan, Hashar is already doing the ground work to make this happen. [1] https://www.mediawiki.org/wiki/Continuous_integration/Workflow_specification
