Deprecation: add warning for required configuration #10348
Assignees
Labels
Improvement
Minor improvement to code
Comments
This was referenced May 24, 2023
humitos
added a commit
that referenced
this issue
May 25, 2023
When we detect a build is built without a Read the Docs configuration file (`.readthedocs.yaml`) we show multiple notifications: - a static warning message in the build detail's page - a persistent on-site notification to all maintainers/admin of the project - send a weekly email (at most) This is the initial step to attempt making users to migrate to our config file v2, giving them a enough window to do this and avoid breaking their builds in the future. Closes #10348
humitos
added a commit
that referenced
this issue
May 30, 2023
This is a continuation of the work done for * #10351 * #10342 * #10348 * #10355 In that work we added notifications, warning messages and finally a feature flag to start failing the builds without a configuration file or using v1. This commit removes all the code for config file v1 and building without a configuration file. Due to that, it also removes the code that allows users to use the older Docker images (testing, latest, stable) This work can be merged once we enable the feature flag to fail the builds for all the projects and we are happy with the results.
humitos
added a commit
that referenced
this issue
Jun 6, 2023
) * Config: deprecated notification for builds without config file When we detect a build is built without a Read the Docs configuration file (`.readthedocs.yaml`) we show multiple notifications: - a static warning message in the build detail's page - a persistent on-site notification to all maintainers/admin of the project - send a weekly email (at most) This is the initial step to attempt making users to migrate to our config file v2, giving them a enough window to do this and avoid breaking their builds in the future. Closes #10348 * Test: invert logic * Notification's copy: feedback from review * It's a function * Notifications: use a scheduled Celery task to send them Instead of sending an onsite notification on each build, we use a scheduled Celery task that runs once a week to send them. It filter projects that are not using the v2 config file. * Feedback from the review * Darker failed on CircleCI because of this * Links pointing to blog post * Add more logging for this task * Space typo * Ignore projects that are potentially spam * Order queryset by PK so we can track it Also, add log for current project in case we need to recover from that task. * Improve query a little more * Make the query to work on .com as well * Query only active subscriptions on .com * Consistency on naming * Only check for `Project.default_version` * Log progress while iterating to know it's moving * Simplify versions query * More logging to the progress * Send only one notification per user The notification will include all the projects the user is admin that are affected by this deprecation. Users will receive at most one notification per week. * Modify email template to include all the projects and dates * Typo * Improve logging * Keep adding logging :) * Db query for active subscriptions on .com * Email subject * Update onsite notification message * Do not set emails just yet * Minor updates * Update emails with new dates
humitos
added a commit
that referenced
this issue
Jun 14, 2023
* Config: deprecated notification for builds without config file When we detect a build is built without a Read the Docs configuration file (`.readthedocs.yaml`) we show multiple notifications: - a static warning message in the build detail's page - a persistent on-site notification to all maintainers/admin of the project - send a weekly email (at most) This is the initial step to attempt making users to migrate to our config file v2, giving them a enough window to do this and avoid breaking their builds in the future. Closes #10348 * Test: invert logic * Build: fail builds without configuration file or using v1 Use a feature flag to decide whether or not hard fail the builds that are not using a configuration file at all or are using v1. This will be useful in the future when we want to make the builds to fail during a reduced period of time to inform users/customers about this deprecation. Related #10351 * Update copy to follow the same style * Upgrade `common/` to use the latest versions for pre-commit This is an attempt to solve the issue with the CircleCI `checks` test. * Dont trigger the task on each build, and linting * Linting * Lint * Latest `common/` * Apply suggestions from code review Co-authored-by: Anthony <[email protected]> --------- Co-authored-by: Anthony <[email protected]>
humitos
added a commit
that referenced
this issue
Oct 23, 2023
…10367) * Deprecation: remove code for config file v1 and default config file This is a continuation of the work done for * #10351 * #10342 * #10348 * #10355 In that work we added notifications, warning messages and finally a feature flag to start failing the builds without a configuration file or using v1. This commit removes all the code for config file v1 and building without a configuration file. Due to that, it also removes the code that allows users to use the older Docker images (testing, latest, stable) This work can be merged once we enable the feature flag to fail the builds for all the projects and we are happy with the results. * Deprecation: update documentation of config file * Deprecation: update config file to remove old keys * Deprecation: update config file v2 docs to deprecate keys - python.version - python.system_packages People should not be using these keys. * Remove auto-install requirements file found on project * Make the deprecated fields read-only as discussed * Remove tasks to send emails about deprecations * Lint & Tests * Remove reference to v1 config file docs * Normalize `get_build_config()` * Update tests for config file * Update tests for collectors * Update tests to follow the new deprecations * Remove invalid tests * More updates related to the config files * Update more tests * Lint
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The first step that we talked about in #10342 was starting to warning projects of the upcoming changes. We definitely want to add this to the build detail page, we could also emit this as a sticky site notification on all pages. This is a more immediate change to start this process so whatever is easiest for now.
Next up, and slightly related to this, we will need to do the marketing level sort of steps. I am separating these out as these steps will come a little later than the immediate steps here.
The text was updated successfully, but these errors were encountered: