CodeClimate testing coverage not working

[orenyk]

I signed in to CodeClimate tonight to see how testing coverage was working and unfortunately it appears not to be. It's weird because in TravisCI it says that it's sending the coverage to CodeClimate during builds. Not sure what's going on, but hopefully it won't be too hard to pin down.

[orenyk]

Ooh, I just realized this might be because the default branch for our repo is master and we've been running all of our tests on other branches? I can't seem to re-add the repo with the default branch set to development (see this link, it might have to be @caseywatts or @mnquintana), but that might be more useful to us. Otherwise we might just have to wait until our next release and see if it kicks in then.

[shippy]

Not sure what happened to the testing coverage -- I seem to remember seeing it updated on the CodeClimate server? Re-adding development as default would definitely be helpful, though. You can view CodeClimate for development here, but you have to manually trigger a re-analysis.

[mnquintana]

development is definitely still set as our default branch on GitHub - it's possible it's not set on Code Climate? I'll take a look.

[shippy]

CodeClimate only does continuous code-evaluation on the branch it was added for. For setting a new default, we'll have to remove it and add it again.

[orenyk]

@mnquintana any update?

[dgoerger]

Given that we have tagged releases, we should consider devving off master and getting rid of the development branch. That's more-standard code practice and currently master is just the latest tagged stable release anyway, sooo. :P

That would also fix the CodeClimate issue, since I think @mnquintana said there's no way to change the default branch (master to dev) on CodeClimate on free accounts.

[dgoerger]

aha, I think the reason we have the master vs development branch nonsense is because our wiki styleguide says to use this dingo of a guide for branching. The guide says to have the master branch for the latest stable release, and development for testing new features.

The guide however fails in that it only seems to acknowledge tagged releases as attributes of the master branch; Github tagged releases aren't linked to any branch at all. We might also have master as a relic from the days when we didn't tag releases (pre-2012).

New branching model proposal:

1. master is unstable, for development purposes. (master is the new development [MITND])
2. tag a release off master; or, branch off master to a rc-v3.5 branch for stabilization so that new code can continue being contributed on master, and then tag releases off the stabilization branch (this latter case is how linux systems e.g. Fedora alpha/rawhide work; the former is how Debian testing works).
3. hotfix stable releases off a special hotfixes branch generated from the tagged release point, or continue off the e.g. rc-v3.5 branch until that release is no-longer supported by the dev team (i.e. when the next tagged release comes out as the new stable tag).

[dgoerger]

ascii flow proposal:

wip-branches      master      release      hotfixes
     o  <--------   o     (stabilization)
      \\            |
       --------->   o   ----->   o   ----->   o     # hotfixes also go
                    |            |rc1       //      # to master if
              -->   o            o   <-------       # they apply there
                    |            |rc2
                   ...           o   <--
                                 |rc3               # if an RC is stable
                                 o                  # re-tag it as final
                                  final             # keep release branch
                                                    # until stable-next

[orenyk]

according to this we can add the same repo multiple times with different default branches, so we should do that now so that our code coverage is being properly tracked via CodeClimate. In terms of our general branching scheme, we can definitely review the options and change things up, but let's discuss that in person.