"Greenkeeper could not be activated" message shows up despite successful build

[derhuerst]

see derhuerst/vbb-stations-with-wifi#1

The build on greenkeeper/initial succeeded, but Greenkeeper opened the issue and still doesn't close it.

Lovely service btw! 😍

[finnp]

Thank you for letting us know about this ☺️

I just looked into it and was not able to find the issue. It does not appear to be broken in general, but I also couldn't find any error related to that specific repository. It might be that we somehow lost or didn't get that status event from GitHub.

Could you delete the greenkeeper/initial branch, remove that repository from Greenkeeper and re-add it? This will trigger another greenkeeper/initial branch. Hopefully after the branch is built, you should get an initial PR.

If not I'll continue looking into why this fails for your repository.

[derhuerst]

this seemed to work, thanks!

[finnp]

Okay great 👍 I'll close this issue as a hiccup then.

[lukechilds]

I'm having a similar issue.

I've got Greenkeeper enabled for all my repos. Does this mean to resolve the issue I need to disable Greenkeeper, delete the branches from all of my repos, and then re-enable Greenkeeper and merge the initial pull requests on all my repos again? Because I have quite a few repos.

[kt3k]

I'm having the same issue on several repos.

kt3k/kocha#27
kt3k/bundle-through#13
kt3k/berber#3
kt3k/geoip-reflector#11
kt3k/view-todo#61
kt3k/vinyl-accumulate#12
kt3k/codecov-karma-example#5
kt3k/gulp-browserify-example#2

In all repos greenkeeper/initial branch got commit statuses (6 success, 2 failure) from CI, but greenkeeper bot says it didn't.

BTW I changed the integration settings from "All repos" to "Only selected repos" recently.

[kt3k]

The above repos got initial PRs from greenkeeper several hours later and then I was able to enable greenkeeper on the all repos. Thanks for the great service!

[KharitonOff]

I have the same issue with greenkeeper:

It looks like Travis set the status on the second commit and greenkeeper couldn't recognise it.
cla-assistant/cla-assistant#235

[derhuerst]

Got it once more. derhuerst/read-audio-tags#1

[Realtin]

@derhuerst Greenkeeper waits 15min for a CI status before assuming there is no CI. In your case The build took about 5 min from being triggered to the begin of the run and then had a total time of ~11 min.

You could open a PR from your greenkeeper/initial branch yourself or if you want I can also reset your repository and you'll get a fresh initial branch. But you could still run into the time out issue. I'll discuss with the team if it makes sense to extend the time we wait for CI statuses.

[derhuerst]

I can fix it by myself, thanks. I'm just letting you know that this issue keeps appearing for me even though it's closed.

[gr2m]

@derhuerst just fyi the timeout was bumped to 30minutes via v2.11.5, so the problem should no longer occur for you

[derhuerst]

I'm don't know how the communication between Travis and greenskeeper works, but it just came to my mind that it might also be related to build delays. On Travis, the macOS build are often delayed be at least 5 minutes, sometimes even 30 minutes. Do you wait for a "build queued", "build running" or "build successful" webhook/event?

[gr2m]

@derhuerst I’ll look into this next week, thanks for caring Jannis 👍

[rmehner]

@derhuerst good points. In fact, we don't listen to Travis, but simply for a commit status to be set. That makes us independent from the CI system in use and allows us to function with other CI services as well.

@Realtin and I discussed looking for the pending status on the commit before we open up the timeout issue, but then again there might be other pending statuses on the commit that are entirely unrelated to CI.