Warn user when pull request events are not enabled

[agjohnson]

The most common support issues I've found with pull request builds are projects that enable the pull request feature and still doesn't get pull request builds. The most common reason for this is that the project web hook does not have Pull requests event enabled on the webhook (for GitHub repositories at least). We store the webhook events enabled, so it seems we have everything to determine:

• Project has a working webhook to GitHub -- pick the first working integration?
• Project webhook has GitHub pull_request event -- stored in JSON blob return from VCS provider

Is this enough to reliably detect when the webhook is not configuring correctly? This would make things much more obvious to users when these builds aren't working correctly.

This could be a warning notification, or could even block the UI from enabling the pull request build feature. Which pattern makes the most sense?

[humitos]

Is this enough to reliably detect when the webhook is not configuring correctly?

I think it's enough, yes. We have that information in integrations.models.Integration.provider_data:

readthedocs.org/readthedocs/integrations/models.py

Lines 292 to 296 in aefe3ff

	provider_data = models.JSONField(
	_('Provider data'),
	null=True,
	blank=True,
	)

This could be a warning notification, or could even block the UI from enabling the pull request build feature. Which pattern makes the most sense?

I think graying out the UI with clear instructions about how to fix the problem makes more sense to me.

[agjohnson]

Disabling the field would definitely be preferable UX, but I'm happy to start small here too, and perhaps firm up the UX in the application template rework.

I suppose we can conditionally alter the form before passing it off to the templates -- if so, disabling the field would be a good option. If we have to do this in templates, that's less than ideal.

[humitos]

This is the query we need to validate the form before presenting it to the user.

In [13]: Integration.objects.filter(
    ...:     project__slug="test-builds",
    ...:     integration_type__in=["github_webhook"],
    ...:     provider_data__events__contains="pull_request",
    ...: ).exists()
Out[13]: True

We need a similar query for GitLab where the provider_data structure is different

It seems a simple change in logic that we can tackle soon. The most important part to me is to make the message clear to the user so they can solve the problem by themselves. I'm adding it to the roadmap so we can prioritize it soon.

[agjohnson]

I'll bump this up to our Q2 list, pull request builds are a good place to focus our energy.