[katello-devel] Merging and Pulling with no wait

[Jeff Weiss]

We did have a lengthy and productive discussion related to this problem at the QE Summit in Brno last week.

I think the major takeaway from that is, we want automated tests running on changes BEFORE they hit master, not only after.

So what we'll be working towards is some system whereby Pull Requests are tested, and some kind of feedback of the automated test results will be posted to the PR comments.

This process should take less than 1 hour after the PR is submitted.  I was planning on using Jenkins, since aside from the PR interaction, the steps are exactly the same as what we do for master today:

1) build rpms from the commit we want to test
2) Install them on fresh vm
3) Run automation against vm

We just need to add
0) Monitor PR's
4) Add feedback to PR



-Jeff

----- Original Message -----
From: "Lukas Zapletal" <lzap at redhat.com>
To: katello-devel at redhat.com
Sent: Wednesday, October 24, 2012 5:07:21 AM
Subject: Re: [katello-devel] Merging and Pulling with no wait

On Tue, Oct 23, 2012 at 03:59:29PM -0600, Jason Rist wrote:
> Tom - you know, I totally agree with you.  I hadn't really thought of
> the Ozzak/Travis stuff that @ehelms and @lzap had been working on, but
> obviously it didn't catch Adam's pylint error, so it's not perfect.
> Perhaps I jumped the gun sending my email out, but my main goal is to
> make the product stable each and every check-in.  Education is great,
> and I like that side of pull-requests, but it's not the primary reason
> for my concern.  Plus, there is nothing stopping someone from viewing
> the committed files via the closed pull request.
>

Just to fine-tune the information - Erik is working on TravicCI-Github
integration and I am just helping him to integrate the new Gemfile. And
it is looking good. No other works on Ozzak, I turned it off because I
thought Eric is done (but he is still tuning the stuff). No more Ozzak,
expect big announcement very soon :-) I want to change ozzak script to
run koji scratch builds against git pull requests.

The git pull you picked as an example is not a good example of request
that should be put on hold for 24 hours. We have having annoying amount
of "fuzzy i18n messages" during our unit test runs and it was literally
blocking Eric from doing anything on Travis (because what you get is 10
MB log which does not pretty work with all that javascript that is on
Travis). And that was reason for the quick merge.

I agree with you that for *important* changes we should not do this and
let everyone to read the patch, but I am totally fine with quick-merging
those tiny things, blockers and cosmetic changes. One can always rise
his hand even after a pull request was merged and if the objections are
reasonable - yes - we have the revert thing.

I have to admit I raised this topic for the first time, but it was after
I saw several big merges I was not totally comfortable with. 

Let's agree on that and if you (or anyone) encounter a "fast&bad" merge,
just scream in the comments.

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine

_______________________________________________
katello-devel mailing list
katello-devel at redhat.com
https://www.redhat.com/mailman/listinfo/katello-devel