Add a project-level configuration for PR builds #7090
Conversation
ericholscher
changed the title
This allows users with the feature flag to enable/disable this feature.
ericholscher
force-pushed
the
feature-flag-pr-builder
branch
from
74b1e75
to
f239442
Compare
There was a problem hiding this comment.
It seems we are not using external_builds_enabled to check if PR builder is configured.
I think we will need a migration that set external_builds_enabled=True on those projects that have the flag, otherwise those projects will show they don't have it enabled in the form.
Probably, the easiest way to do this is by removing the Feature flag completely from the code and just use external_builds_enabled to check if enabled or not.
| So, you can enable this feature by sending us an `email <mailto:support@readthedocs.org>`__ including your project URL. | ||
| This feature is currently enabled for a subset of our projects while being rolled out. | ||
| You can check to see if your project has it enabled by looking at the :guilabel:`Admin > Advanced settings` and look for :guilabel:`Build pull requests for this project`. | ||
| We are rolling this feature out based on the projects age on Read the Docs, |
There was a problem hiding this comment.
| We are rolling this feature out based on the projects age on Read the Docs, | |
| We are rolling this feature out based on the projects' age on Read the Docs, |
I always confuse this, so maybe I'm wrong here :)
|
@humitos the goal is not to release this all at once, but slowly roll it out to more projects via the feature flag. I've updated the migration. |
|
I guess we could ship this widely, and just scale it up as users enable it, but that worried me a little bit because it could swamp our servers, but maybe it's time? |
readthedocs/projects/migrations/0050_migrate_external_builds.py
Outdated
Show resolved
Hide resolved
| pytest-custom-exit-code==0.3.0 | ||
| pytest-django==3.6.0 | ||
| pytest-django==3.8.0 |
There was a problem hiding this comment.
I upgraded these because then it gave me proper failures on the migrations instead of blowing up :)
| # TODO: Remove this after migrations | ||
| null=True, |
There was a problem hiding this comment.
This is not needed when using a default= value. I'd remove it in this PR instead of forcing us to create a new one later.
There was a problem hiding this comment.
That only works on the new code though, when we run the migration and the old code is still running, it will blow up the DB.
This allows users with the feature flag to enable/disable this feature.