>> Hello devs,
>> since there was a discussion on foreman-dev IRC channel recently about merging
>> PRs in Foreman core even if there's some build failed, I talked to few people
>> and decided to describe here what I think is current way of how it works. I'm
>> also attaching one suggestion at the end that came up after the discussion.
>> Please, add questions, comments or simple +1 so we all know whether we're on
>> the same page.
>> Core PR runs 7 checks - foreman, katello, codeclimate, hound, prprocessor,
>> upgrade, continuous-integration/travis-ci/pr. In ideal case they are all green
>> and after review, the PR is merged. There are several cases where we can merge
>> even if the PR is red.
>> 1) codeclimate is red
>> This can be ignored, we never agreed on using this as a hard metric for the
>> PR. The motivation to introduce it was mainly to save some time to reviewer.
>> We don't have to run it manually to get indications whether there's something
>> introducing a big complexity . From my experience it sometimes leads to
>> worse code, since author splits the logic into more methods to lower e.g.
>> cyclomatic complexity but it should be judged separately in every case.
> It should be taken care of whenever possible. Most of the times it's
> certainly right and notices typical problems like stupidly long classes,
> duplication, etc…
> https://codeclimate.com/github/rails/rails itself enforces it unless a
> maintainer vets the PR. (ad hominem fallacy, I know)
>> 2) foreman is red
>> This can happen because of intermittent tests failures. If the PR is clearly
>> not causing new ones and commiter is aware of this error, the PR is merged
>> with message like "test unrelated" comments. If we are not sure, we retrigger
>> the run,
>> If Foreman develop branch is broken, we need to merge the PR to fix it so this
>> is another exception. Usually we trigger the jenkins job manually first to see
>> that the PR fixes the issue.
> Makes sense to me, generally. The only con I've seen since I started
> contributing is that few people care to fix intermittent tests, which
> caused the job to be red for weeks at times
The problem with intermittent issues, or broken builds that are not related
to the PR itself, is that it's not clear whether somebody is already
working on it or not.
For intermittent issues, would it make sense to track every such an
issue in redmine (we perhaps already do)
and add vote for it every time it occurs (not sure if one person can
vote multiple times for some issue).
The goal would be to take this issues as one input of planning and
making sure we put it on the iteration.
For the master failures, having a foreman-dev thread as soon as it
appears and either
inform that one is working on fixing that, or ask for somebody else to
look into it, could work.
Also irc status about that would be useful to know right away what's going on.
>> 3) katello is red
>> If katello becomes red only for this PR, we analyze what causes it. Usually it
>> means that we change some internal things that have impact on Katello. In such
>> case, we're doing our best to send a fixing PR to Katello or we ping someone
>> with better knowledge in this area. We don't merge the PR until it's resolved,
>> then usually we merge both parts at the same time.
> This sounds good. Ideally the contributor sends the patch to Katello, please.
>> If it turns out there are more PRs that are failing with same errors, we merge
>> PRs if we're sure they don't introduce new Katello failures. At this time,
>> we're not blocking merges until Katello is green again. (*) here the
>> suggestion applies
> I don't think this is fair. If the Katello job is red, it's our
> responsibility to bring it back to green. When the causes for the job to
> be red are unknown, merging more stuff in Foreman will certainly NOT
> make it easier to understand them. In fact it may just aggravate the
> problem. So I would say no - at least on PRs I'm reviewing, I'm not
> merging if Katello is red.
If it's clear the PR is not the reason for the failures, there should
not be a reason
for blocking the PR from merging. For the investigation, one needs to
find the first
occurrence of that error in the history, which should be enough to
find exact time
when it started happening.
>> 4) upgrade is red
>> this is very similar to katello job, if there's some issue in upgrade, we
>> should not merge the PR. I remember though, there was a time when we knew the
>> job is broken which fall under "known to be broken" category.
> Same as 3.
This sound more like broken master case for me.
>> 5) There's no 5, all the rest must be green. Sometimes hound service does not
>> respond and remains in "running" state, then it's retriggered by the reviewer.
>> prprocessor and travis must always be happy.
>> Now the promised suggestion. When we see katello/upgrade job is broken on
>> multiple PRs, the first reviewer who spots it should notify the rest of
>> developers about "from now on, we ignore tests XY". The ideal channel seems to
>> be this list. This helps Katello devs to find out when it started, what were
>> the commits that first induced it.
> Sorry, I don't think this is a better idea than the current (unspoken)
> approach to block PRs until Katello is merged. It's good you started
> this thread, as clearly people have different assumptions on this topic
> as we didn't talk about it much.
I agree with Marek here, provided it's clear we are in 'katello broken' mode,
what test failures can be ignored for now and that somebody is working
on resolving them.
The last time, it seemed the issue was the Katello team was not even
aware of them
and found it out accidentally (please correct me if that was not the case)
> If we reach to some conclusions, updating
> Foreman :: Contribute with them would be good to have
> some reference set in stone (or in bytes (: ).
+1 on documenting the result of this discussion there.
On Tue, Aug 29, 2017 at 11:25 AM, Daniel Lobato Garcia wrote:
> On 08/28, Marek Hulán wrote:
>>  https://groups.google.com/forum/#!topic/foreman-dev/p7ESagXwNwk
>> Thanks for comments
>> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
>> For more options, visit https://groups.google.com/d/optout.
> Daniel Lobato Garcia
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
> For more options, visit https://groups.google.com/d/optout.