[katello-devel] automated testing, who's doing what? (was: Re: Merging and Pulling with no wait)

[Tom McKay]

----- Original Message -----
> From: "Jeff Weiss" <jweiss at redhat.com>
> To: "Lukas Zapletal" <lzap at redhat.com>
> Cc: katello-devel at redhat.com
> Sent: Wednesday, October 24, 2012 2:32:34 PM
> Subject: Re: [katello-devel] Merging and Pulling with no wait
> 
> 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
> 

Is everyone working together on the automation stuff or individually? Jeff, are you working with Lukas and Eric? I hope we're pooling resources and efforts.


> ----- 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
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
>