Mergeable PR said as needing to be rebased

[jotak]

It looks like there is a bug with the usage of the Mergeable flag here:

ci-chat-bot/manager.go

Lines 945 to 947 in 9dac707

	if !pr.Mergeable {
	return nil, fmt.Errorf("pull request %s needs to be rebased to branch %s", spec, pr.Base.Ref)
	}

This value can not only be true or false, but also null, cf https://docs.github.com/en/rest/reference/pulls#get-a-pull-request, when github is refreshing this flag. And it happens to us quite often that a PR is said needing rebase although it's actually mergeable; repeating the cluster-bot command several times in a row would ultimately make it work.

So, would it be possible to either have a small retry mechanism when Mergeable is null, or alternatively, allow to build on non-mergeable PRs ?

[jotak]

Did someone have a look at that? Thanks

[bradmwilliams]

We decode the json response, from GitHub, into a GitHubPullRequest. This means that if/when Mergeable is returned as null, from GitHub, it will only ever be False to us. While I understand that this may not be ideal, the best we can probably do here is to add some more verbiage to the message.
As far as allowing builds of non-mergeable PR's, I'm not a big fan of that idea because you'd be building/testing code that'll eventually need to be rebased, regardless, and therefore should then be (re-)tested again.

[jotak]

The current message is indeed wrong regarding the situation, I agree that at least it should be modified. Though I don't understand why having a quick retry mechanism isn't even an option, since in general, manually retrying just a couple of seconds later works.

[memodi]

Hi @bradmwilliams - adding more/changed verbiage would certainly will helpful while it verifies the merge-ability in the back.ground. Let me know if we need to create an JIRA issue for this. Also +1 to @jotak retry idea if that's possible. Thanks!

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[bradmwilliams]

/remove-lifecycle stale

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[bradmwilliams]

/remove-lifecycle rotten