[katello-devel] Merging and Pulling with no wait

[Lukas Zapletal]

I think we can roll out this version, RPM building is not what we can do
in Travis and since Jeff has these plans - we would duplicate the
effort.

Until Jeff implements the stuff, I can run Koji builds from Ozzak.

LZ

On Wed, Oct 24, 2012 at 02:51:23PM -0400, Eric Helms wrote:
> For your information, working with Lukas, we have put together a
> Travis config that will run on every pull request and every update
> to a pull request the following:
> 
> - CLI unit tests
> - pylint
> - SCSS compilation
> - RSpec unit tests
> 
> And run them against both Ruby 1.8.7 and Ruby 1.9.3
> 
> Figuring out how to incorporate testing RPM builds and installation
> will make the pull request testing more robust.  As long as what is
> output to the pull request does not contain closed door links and
> provides developers with meaningful information on how to solve
> their problems.
> 
> Jeff, I have done some prior investigation into Jenkins with pull
> requests if you want to compare notes at any point.
> 
> -Eric
> 
> On 10/24/2012 02:32 PM, Jeff Weiss wrote:
> >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.
> >
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
Later,

 Lukas "lzap" Zapletal
 #katello #systemengine