Re: [cross-project-issues-dev] Enforce Gerrit for Simrel?

[Mickael Istria <mistria@xxxxxxxxxx>]

On 01/07/2016 07:33 PM, Stephan Herrmann wrote:

I like gerrit for long-running tests so I can start the next task
while tests are still running on the server.
Running b3 validation in the b3 editor is not what I call a long-running test,
I rather feel it convenient to validate locally, before pushing to the server.

Yes, that's a good practice; but not everyone follows such good practices ;)

Does the Gerrit validation job perform additional validations that I don't
get in the IDE?

To be fair, I don't know... Maybe David can tell that.
But the plan seems to be to add more and more automated tests that could run on Gerrit patches.

Also my gut feelings says, that if everybody has to go through gerrit,
we will see lots of rebase-jobs piling up, just because during one
validation job s.o. else has merged his changes and hence other changes
cannot be merged before doing a rebase, triggering another validation job etc.
I'm not sure if gerrit is perfect for this many concurrent pushes to the
same repo in such a short time frame.

Currently, Simrel seems to have maximum 10 commits per day. So that's definitely a problem (the worst sequence of Rebase could require 55 builds to validate those 10 commits...)
The submit type for SimRel on Gerrit is "Merge if Necessary", meaning that rebase are not mandatory. However, this creates into the repository some merge commits that make that what's tested on Gerrit can be different that what's on HEAD after the merge. As we expect the changes to be "atomic" and relatively isolated at the time, and since we still have a CI build to validate the actual HEAD, it seems to be a good trade-off.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets