Description
Hi again,
i was very happy to know that my pull request #616 got merged a few days ago so I could get rid of my fork. Sadly I figured out that using the last state of the repo the process stucks/hangs and the memory usage increased to 4.6Gib.
So I decided to use the git-bisect to figure out when was the bug introduced. As starting point i put following commit f977cd1 which was added some days before I opened my fork and went the whole way through testing every step.
$ git bisect start
$ git bisect bad
$ git bisect good f977cd107243afa382be0f69db27119d0450985f
At each step i build the gem and tested agains my project locally and not from the docker.
As a result i got following:
372875f74838e5d7ab38bc337ec4333b540c13cd is the first bad commit
commit 372875f74838e5d7ab38bc337ec4333b540c13cd
Author: Hunter Haugen <hunter@puppet.com>
Date: Thu Feb 8 16:28:39 2018 -0800
Use git history to find PRs in a tag instead of time
Fixes #617
Before this change PRs were associated with tags by the merge date of
the PR, regardless of git branching history. In this change the oldest
tag in which the merge commit of each PR occurs in is determined by
using the Github compare API. That association is then used to sort PRs
into their respective release.
This change uses caching of commit history fetching and comparisons for
speedup.
:040000 040000 85ea95fe6eee626debc717ad31c2e56b790bd5bf
ace182352a34c7ece0d0f4c76e0e5b068d152b99 M lib
:040000 040000 7bf68589dad03500e971f992cfa4194824e60177
bd10aac7205bb84900a4a07a7ea3c3a634712e5c M spec
I didn't had time to look into the commit. I will again open a fork rebasing to the commit before the bug and cherry pick the commits from my pull request... until we find a solution.
Best Arturo